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;
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
>>>
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
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
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
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
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
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
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
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
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
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
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
>
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
>
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
23 matches
Mail list logo
