emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Max Nikulin
Subject: Re: Proposal: 'executable' org-capture-templaes
Date: Sun, 19 Jun 2022 17:53:40 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

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. 87mteiq6ou.fsf@gmail.com">https://list.orgmode.org/87mteiq6ou.fsf@gmail.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]