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

[Ihor Radchenko <yantar92@gmail.com>]

Max Nikulin <manikulin@gmail.com> writes:

>>> 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.

Sure. I was hinting about such functionality in the new library we are
discussing. Multiple capture menus are not possible now anyway, so it
will be a new feature if we decide that we need it (I am not 100% sure
if having multiple menus is not going to be confusing).

>> 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.

I am not sure which behavior you have in mind.
What I was thinking as a conservative implementation that would not
introduce any new features is replacing the old menu with the new one
every time the same menu is called. So, every time the user calls menu
(e.g. capture menu), only the last capture environment is preserved. The
previous, potentially unfinished, capture menus will be destroyed.

Best,
Ihor