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....@gmail.com