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

[Arthur Miller <arthur.miller@live.com>]

Max Nikulin <manikulin@gmail.com> writes:

> On 11/06/2022 12:26, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>>> However if two org-protocol handlers are launched without specified
>>> template then behavior of Org becomes confusing. I meant this case.
>>> Currently reading key from minibuffer serves as a kind of
>>> synchronization tool.
>>>
>>> Imagine what would happen if Emacs decided to show several capture menus
>>> with keymap non-blocking interface in different virtual desktops.
>>> Capture data should be saved somewhere till the user would discover
>>> initially hidden menu.
>> 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.
>
> There are enough side band communication channels in Org. I did not remember a
> variable from which properties are obtained. Before I have realized that it is
> `org-store-link-plist', I noticed at least `org-overriding-default-time',
> `org-capture-initial'. Unsure that the list is complete.

I have a question here: what is meant by this:

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

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.

I just haven't done that in demo yet, so that is why I said when I posted the
code, I haven't implemented that "correctly", bit I am quite sure it is not very
hard to do.

Am I correct about the principle? If not, than I will have to rething about it.