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

[Max Nikulin <manikulin@gmail.com>]

On 18/06/2022 22:05, Arthur Miller wrote:
> Max Nikulin writes:
>> On 11/06/2022 12:26, Ihor Radchenko wrote:
>>> Max Nikulin writes:
>>>
>>>> Imagine what would happen if Emacs decided to show several capture menus
>>>> with keymap non-blocking interface in different virtual desktops.
> 
> Different Emacs processes, or just different Emacs frames?

I mean single Emacs process perhaps with multiple frames spread over 
monitors and virtual desktops. I am unsure if Emacs can create windows 
for different X11 displays, but let's leave it aside and inter-process 
file locks as well.

> In case of different Emacs processes, there is no way to guarantee consistence
> unless one locks file in the file system. Windows can do it, I am not sure what
> is Linux API to do this, don't know if Emacs exposes this functionality, have
> never tried.
> 
> Otherewise, if it is only different Emacs frames/clients, the capture should
> always find the capture buffer and return that one instead of creating new
> ones. That way there is only one capture buffer, so multiple captures should not
> be possible, i.el, it creates same effect as locking the input to minibuffer. I
> am not sure how org-capture does, I haven't studied the code in-depth yet, but
> what I see currently a user cancels it with C-c C-k. org-capture buffer could
> setup hooks to clean everything, even if user kills buffer by other means, c-x
> k, or whatever. It maybe already does, as said I haven't looked at those
> details.

Arthur, be reasonably skeptical concerning my ideas or suggestions, it 
seems I have not managed to convince e.g. Ihor.

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.

Waiting for return value to get capture template is not possible any 
more. A kind of continuations should be passed to the function creating 
menu buffer instead. E.g. it can be some state object that stores 
snapshot of data necessary to fill capture template, export options, 
etc. and functions in menu entries that accept this state object as 
argument or obtain it from a dynamic variable. The state object likely 
should be a buffer-local variable. For non-blocking menu, entries should 
contain callbacks or menu may have single callback that is able to 
process static data from menu entries.

As a result, capture can not be processed till filling of a template 
(and so till adding it to the target buffer) within a single function. 
Instead first function prepares set of callbacks and renders a buffer 
with menu. When user activates a menu entry, a callback either just 
modifies the state object to change some option or starts some action 
(fills capture template and inserts result to the target document) and 
notifies caller that the menu should be destroyed. E.g. if some special 
symbol is returned from the menu entry callback than it means change of 
some option, so menu should be retained, otherwise it is action and the 
menu buffer is not necessary any more.

So despite I earlier opposed to executable menu entries, they are quite 
natural way to implement non-blocking menu. State object specific to 
menu instance should be added in some way convenient for developers.

More work may be necessary however to make org-capture really convenient 
and reliable. Capture menu should display some summary of captured data 
otherwise it is impossible to decide which template should be chosen in 
the case of several simultaneous capture buffers. It is better to save 
capture data somewhere on disk while while menu is displayed to recover 
it after a crash.

> I agree with you that completing read is a good alternative, but it is a
> bit like discussion about GUI vs. terminal. I am personally heavy user
> of Helm, but not everyone is I believe.

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.

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