Re: Proposal: 'executable' org-capture-templaes

[Max Nikulin <manikulin@gmail.com>]

On 19/06/2022 22:34, Arthur Miller wrote:
> Max Nikulin writes:
>> I believe, multiple capture menus should be possible in parallel even within
>> single frame since it may contain several windows and user experience should be
>> better than now. Keymap-based selection opens a road in this direction since
>> menu may be non-modal, but it requires a bit different design.
> 
> That sounds like a new feature. You are correct, keymaps do open in that
> direction. That would be possible to tuck on the routine that saves the
> temporary buffer (whatever is called with C-c C-c). When user press C-c C-c in a
> capture buffer, that is the only time when interaction with real a file on the
> disk happends, right?

I am going through older messages trying to find possible sources of 
different assumptions. I am at least partially repeating myself, but I 
consider this point as an important one.

When a capture template is selected, `org-capture-fill-template' adds 
capture text to the proper heading of the target document. Capture 
windows display narrowed down buffers of target documents. Disk 
operations happen on C-c C-s hit by user (it can be done for a capture 
buffer as well) or on autosave timer. Aborting capture by C-c C-k 
reverts the change by erasing earlier added text from the target 
document. It is safe to have multiple capture buffers, but some amount 
of work is required to make parallel menu buffers straightforward.

>> I mentioned completing-read because I consider it as a test of API quality. It
>> should be possible to plug alternative menu implementation and completing read
>> may be a simple enough variant. It is blocking, but in the case of capture "push
>> to capture queue" could be used to postpone the action.
> 
> I don't think it matters there that completing read is blocking. Users do
> completing read just to pick one action to get executed. I don't think I
> understand how qeue of captures to do would work, to be honest.

It is related to code calling menu rather than implementation of menu. 
It is a way to improve handling of parallel capture template selection 
menus even with `org-mks'. Certainly I expect that new menu library will 
not add any new obstacles. Assume a modal template selection is 
configured, e.g. based on completing read and such "menu" is currently 
active. The user may switch to another application and request new 
capture through "org-protocol:" URI. The best way to handle such case 
from my point of view is to detect that the menu is active, collect 
values necessary to expand template and put this capture state to some 
queue. As soon as the user selects template for the capture started 
earlier, next state is popped from the queue and next template selection 
prompt is activated.

>> P.S. Notice text properties for entries in the following modal menu:
>> Timothy to emacs-orgmode. [PATCH] New remote resource download policy. Sun, 12
>> Jun 2022 22:43:07 +0800. https://list.orgmode.org/87mteiq6ou.fsf@gmail.com
> 
> I am not sure what do you bring that cod up? I looked at the link, but I just
> see text styling with faces. Do  you mean to use text properties to communicate
> the state? Sure text properties can be used for different things, but already
> have "template" (a list) we are passing around. Isn't it sufficient as a state
> carrier. You can push/pop things off of it to communicate whatever. Forgive me
> if I don't understand what you meant there.

At that moment I considered it as a feature request to add text 
properties to keys displayed in the menu. Later I realized that it is 
not a problem even for `org-mks' since strings with keys may be 
propertized in advance.

It is unrelated to user state, but the patch adds another implementation 
of menu. I hope that it will be possible to avoid dedicated menu code 
for this particular query and rely on org-select your proposed.

Timothy wrote that a reason for custom menu was modal nature of 
`org-mks', so it would made impossible to inspect the document before 
decision if a remote URL should be allowed. org-select should relieve 
this limitation.