Bruno Barbier writes:
>>> (concat "\\"
>>> "This content is pending. "
>>> "\\[org-pending-describe-reglock-at-point]"
>>> " to know more."
>>
>> You set a similar help-echo string in two places. It is a good
>> candidate to fac
Hi Ihor,
Ihor Radchenko writes:
> Bruno Barbier writes:
>
[...]
>>> Ideally, we should have no hard-coded color names.
>>
[...]
> If you have no ideas about faces to inherit from, better keep hard-coded
> colors.
>
> (Also, this is not too critical; just something nice to have for better
> in
Bruno Barbier writes:
>> Then, there is no point in this function - users will never know about
>> it. Maybe you do expose it as a button, but also supply a yes/no prompt
>> asking for confirmation?
>>
>
> The function 'org-pending-unlock-NOW!' is part of the API, it's not a
> command Emacs end u
Hi Ihor,
Ihor Radchenko writes:
> Bruno Barbier writes:
>
I added a function 'org-pending-unlock-NOW!' which unlock the region
immediately. The uppercase "NOW!" emphasizes that it's not the
"safe" way to unlock a region.
>>>
>>> I expect to see this function called by some kin
Bruno Barbier writes:
>>> I added a function 'org-pending-unlock-NOW!' which unlock the region
>>> immediately. The uppercase "NOW!" emphasizes that it's not the
>>> "safe" way to unlock a region.
>>
>> I expect to see this function called by some kind of button in the
>> details buffer, so that
Hi Ihor,
Ihor Radchenko writes:
> Bruno Barbier writes:
>
>> I added a function 'org-pending-unlock-NOW!' which unlock the region
>> immediately. The uppercase "NOW!" emphasizes that it's not the
>> "safe" way to unlock a region.
>
> I expect to see this function called by some kind of butto
Bruno Barbier writes:
> I've just pushed a new version.
Thanks!
> I added a function 'org-pending-unlock-NOW!' which unlock the region
> immediately. The uppercase "NOW!" emphasizes that it's not the
> "safe" way to unlock a region.
I expect to see this function called by some kind of button
Hi Ihor,
Ihor Radchenko writes:
> Bruno Barbier writes:
>
>> About how much to decorate, it depends on the user, I guess. For
>> example, when org-pending is used for org babel, it should be obvious
>> that one has to click on "#+RESULTS:".
>>
>> The current decoration is not the best for di
Bruno Barbier writes:
>>- After failure, the "!" fringe indicator is visible, but it is not
>> obvious at all that user can click to get details
>> I first tried to click on the fringe itself to no avail. Then, I
>> randomly clicked on the text and got the description buffer; b
Hi Ihor,
Ihor Radchenko writes:
> Bruno Barbier writes:
>
> I have one suggestion though. You now do
>
> Use the function ON-OUTCOME to update the region with the outcome; if it
> is nil, set it to the function `org-pending-on-outcome-replace'.
>
> However, `org-pending' is defined vi
Bruno Barbier writes:
>> Fair. Although, it feels like a common use case to replace the region
>> with :success value. Maybe the library should provide some ready-to-use
>> functions that can be used as the value of :on-outcome.
>
> I've recycled the old function used by `org-pending-user-edit',
Ihor Radchenko writes:
> Bruno Barbier writes:
>
;;(org-pending-send-update my-rlock (list :progress "Not ready
yet."))
;;(org-pending-send-update my-rlock (list :progress "Coming
soon."))
>>>
>>> Should the progress message always be a string?
>>
>> No.
Bruno Barbier writes:
> ... I'm now using using a fully working example.
Thanks!
I will first reply to you email inline and then common further on your
changes from the branch.
>>> ;;(org-pending-send-update my-rlock (list :progress "Not ready
>>> yet."))
>>> ;;(org-pending-se
Ihor Radchenko writes:
> Bruno Barbier writes:
>
> I am attaching some minor edits I'd like to propose on top of your
> latest branch.
I've applied your patch. Thanks.
> Also, some more questions.
>
>> ;;(setq my-rlock
>> ;; (org-pending (cons (point) (mark))
>> ;;
Bruno Barbier writes:
> I've pushed the update to my public branch.
Thanks!
I am attaching some minor edits I'd like to propose on top of your
latest branch.
Also, some more questions.
> ;;(setq my-rlock
> ;; (org-pending (cons (point) (mark))
> ;;
Hi Ihor,
Ihor Radchenko writes:
> Bruno Barbier writes:
>
>> I've pushed the modification to my branch.
>
> Thanks! Let's work further on the top comment.
>
>> ;; To lock a region, you need to do something like this:
>
> I think "something like this" can be just dropped.
Sorry, I'm failing t
Bruno Barbier writes:
> I've pushed the modification to my branch.
Thanks! Let's work further on the top comment.
> ;; To lock a region, you need to do something like this:
I think "something like this" can be just dropped.
> ;;1. Call the function `org-pending' with the region to lock; u
Thanks for the review Ihor!
>> Thanks. I've improved the documentation of `org-pending' to mention
>> that one may want to customize the following fields of a reglock:
>> before-kill-function, user-cancel-function and
>> insert-details-function. And, also, I added that one can attach
>> custom
Bruno Barbier writes:
> Thanks for the review.
>
> I've pushed a new version, hoping to decrease the number of dislikes
> ;-)
Thanks!
>>> Cancel is handled by sending a failure message (see
>>> `org-pending-cancel'). It's customizable using the reglock field
>>> ~org-pending-reglock-user-can
Hi Ihor,
Thanks for the review.
I've pushed a new version, hoping to decrease the number of dislikes
;-)
Ihor Radchenko writes:
> Bruno Barbier writes:
>
>>> I have a further request on interaction with penreg objects.
>>> I feel that it is not ideal that overlays associated with penreg obj
Bruno Barbier writes:
>> I have a further request on interaction with penreg objects.
>> I feel that it is not ideal that overlays associated with penreg objects
>> cannot be fully controlled by the callers.
>
> I'm trying to limit the public API surface. I don't think we should
> leak that we a
Rudolf Adamkovič writes:
>
> +1 for the full name.
>
> Searching 'M-x' for 'region' gives 229 results on my Emacs, so there is
> a precedent. In fact, when I first read the name 'reglock', I took
> 'reg' for *not* a region, but register or registry, precisely because
> Emacs consistently spell
Ihor Radchenko writes:
> Bruno Barbier writes:
>
>> I've pushed an update that should address most of your comments.
>
> Thanks!
>
>> I've found a better name: I'm now calling it a "lock". So I renamed
>> "PENREG" into "REGLOCK" as "region lock". The structure is now
>> `org-pending-reglock'.
Ihor Radchenko writes:
>> I've found a better name: I'm now calling it a "lock". So I renamed
>> "PENREG" into "REGLOCK" as "region lock". The structure is now
>> `org-pending-reglock'.
>
> I slightly dislike short names and would prefer region-lock, but not a
> big deal - it is just my persona
Bruno Barbier writes:
> I've pushed an update that should address most of your comments.
Thanks!
> I've found a better name: I'm now calling it a "lock". So I renamed
> "PENREG" into "REGLOCK" as "region lock". The structure is now
> `org-pending-reglock'.
I slightly dislike short names and
Hi Ihor,
Thanks for your review and detailed explanations.
I've pushed an update that should address most of your comments.
Let me answer point by point below.
Ihor Radchenko writes:
> Bruno Barbier writes:
>
>>> I feel that org-pending-penreg (org-pending-) is
>>> redundant. Maybe better
Bruno Barbier writes:
>> I feel that org-pending-penreg (org-pending-) is
>> redundant. Maybe better use org-pending-region?
>
> PENREG is the name of the structure; the "org-pending" is the
> mandatory library prefix; this mechanically gives the name. A PENDREG
> object is not a "region" in Ema
Ihor Radchenko writes:
Thanks for your review Ihor!
> Bruno Barbier writes:
>
>> I rewrote the API, rename many things, moved the code around and
>> sorted everything into heading/subheading sections. This is hopefully
>> less confusing and a lot simpler; and the documentation hopefully
>>
Bruno Barbier writes:
> I rewrote the API, rename many things, moved the code around and
> sorted everything into heading/subheading sections. This is hopefully
> less confusing and a lot simpler; and the documentation hopefully
> explains better how to use it.
Thanks! It does look more clear.
Ihor Radchenko writes:
> Bruno Barbier writes:
>> Would "lisp/org-pending.el" be OK ? Or do you see a better place/name ?
>
> org-pending sounds fine. Maybe org-pending-text to be more explicit.
I've picked: "org-pending"; it's shorter and can by used as a prefix.
Thanks.
> Similar to proc
Bruno Barbier writes:
>> While reading the library header and `org-pending' docstring (btw, it
>> should probably be a separate library, not a part of org-macs),
>
> I was feeling more and more like squatting the wrong file :-)
>
> Would "lisp/org-pending.el" be OK ? Or do you see a better place
Hi Ihor,
Ihor Radchenko writes:
> Thanks!
> I have some minor concerns about implementation, but you clearly
> demonstrated the things can be working in general.
Thanks!
> While reading the library header and `org-pending' docstring (btw, it
> should probably be a separate library, not a par
Bruno Barbier writes:
>> I now think that overlays are the right way; the /pending content/ is
>> attached to one buffer: a base or a clone; this is for the user to
>> decide.
>>
>> I will manually add text properties, below the overlay, to mark the text
>> as /pending/, so that pending contents
Hi,
Bruno Barbier writes:
> Ihor Radchenko writes:
>
>> Bruno Barbier writes:
>>
Overlays are not transferred when a new indirect buffer is created (for
example, by org-capture, or by user). So, it will be (1) impossible to
see pending overlays in indirect buffers; (2) user ed
Ihor Radchenko writes:
> Bruno Barbier writes:
>
>>> Overlays are not transferred when a new indirect buffer is created (for
>>> example, by org-capture, or by user). So, it will be (1) impossible to
>>> see pending overlays in indirect buffers; (2) user edits of pending text
>>> from indirect b
Bruno Barbier writes:
>> Overlays are not transferred when a new indirect buffer is created (for
>> example, by org-capture, or by user). So, it will be (1) impossible to
>> see pending overlays in indirect buffers; (2) user edits of pending text
>> from indirect buffer will not be prevented.
>
>
Hi Ihor,
Ihor Radchenko writes:
[...]
>> I've tried to fully describe the feature in the new section "Pending
>> contents", in the file `lisp/org-macs.el'.
>
> I have one general concern about the implementation.
>
> Overlays are not transferred when a new indirect buffer is created (for
> exam
Bruno Barbier writes:
> I've publish the proposed changes as a branch. You can fecth that
> branch there:
> ┌
> │ repo: https://framagit.org/brubar/org-mode-mirror
> │ branch: bba-pending-contents
> └
Thanks!
> I've tried to fully describe the feature in the new section "Pending
> co
Hi,
Bruno Barbier writes:
> Hi Matt,
[...]
>> Since this thread is dedicated to blocking, let me share my thoughts on that
>> subject.
>
> I guess I should start a new thread then :)
I finally got a new version. I've renamed the proposed feature "pending
contents", that is, some contents t
39 matches
Mail list logo
