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

[Max Nikulin]

On 18/06/2022 15:25, Ihor Radchenko wrote:
> Max Nikulin writes:
>
> > > Note that there is not much happening when capture menu is called. Only
> > > the link is stored into link ting. Otherwise, no capture data is
> > > altered. All the fragile staff is happening after selecting capture
> > > template.
> >
> > Ihor, magic is impossible. If several captures may be requested in
> > parallel then snapshot of data required to fill capture template should
> > be stored somewhere at the moment when capture is initiated. Otherwise
> > the user may kill the buffer she is going to capture before selecting
> > particular template.
>
> Sure. That somewhere can be buffer-local variable inside the capture
> menu buffer. Or global variable. Or closure. How is it relevant to the
> capture menu?

Before menu buffer is created, caller can not assign a buffer-local 
variable. So to be transparent for snapshot of capture data, menu should 
support such variable and should pass it further when template is 
chosen. Otherwise the capture data may be lost with temporary buffer. 
The function calling menu should gather values from all variables 
necessary for capture to build some state passed to menu implementation.

> Of course, using global variables will limit things to a single capture,
> but it just means that if a user starts capture, leaves the capture menu
> buffer, and then starts another capture, only the last capture will be
> handled. Just like we have now.

Now user may leave capture menu by either selection of a template or by 
aborting menu. In the case of keymap-based menu there is no such 
restriction, so org-capture and menu implementation should be adjusted 
in some way to avoid bad surprises for users.

Currently several capture menu instances may be requested though 
org-protocol (or calling org-capture from emacsclient). The behavior is 
rather confusing. New menu may help to fix the issue, that is why I 
raised the question about parallel captures.