emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Proposal: 'executable' org-capture-templaes
Date: Sun, 19 Jun 2022 17:53:40 +0700	[thread overview]
Message-ID: <t8mv7l$qk4$1@ciao.gmane.io> (raw)
In-Reply-To: <AM9PR09MB4977774DC5F189646681FDB496AE9@AM9PR09MB4977.eurprd09.prod.outlook.com>

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. 

  reply	other threads:[~2022-06-19 10:54 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-26 15:27 Proposal: 'executable' org-capture-templaes Arthur Miller
2022-05-27  5:27 ` Ihor Radchenko
2022-05-27 12:17   ` Arthur Miller
2022-05-27 14:35     ` Max Nikulin
2022-05-28  3:51     ` Ihor Radchenko
2022-05-30  2:04       ` Arthur Miller
2022-05-30  5:05         ` Ihor Radchenko
2022-05-30 12:40           ` Arthur Miller
2022-05-31  4:58             ` Ihor Radchenko
2022-05-31 14:46               ` Arthur Miller
2022-06-04 15:35               ` Arthur Miller
2022-06-05  0:04                 ` Ihor Radchenko
2022-06-05 15:16                   ` Arthur Miller
2022-06-05 23:05                     ` Tim Cross
2022-06-08 12:43                       ` Ihor Radchenko
2022-06-08 21:13                         ` Tim Cross
2022-06-09  4:00                           ` Ihor Radchenko
2022-06-17  4:40                         ` Arthur Miller
2022-06-18  4:03                           ` Ihor Radchenko
2022-06-18  4:26                             ` Tim Cross
2022-06-18 12:25                       ` Max Nikulin
2022-06-08 12:24                     ` Ihor Radchenko
2022-06-05  7:36                 ` Max Nikulin
2022-06-05 15:07                   ` Arthur Miller
2022-06-06 17:06                     ` Max Nikulin
2022-06-07  3:09                       ` Samuel Wales
2022-06-07  3:16                         ` Samuel Wales
2022-06-08 12:48                           ` Ihor Radchenko
2022-06-10 16:53                         ` Max Nikulin
2022-06-11  5:26                           ` Ihor Radchenko
2022-06-18  8:18                             ` Max Nikulin
2022-06-18  8:25                               ` Ihor Radchenko
2022-06-19 11:20                                 ` Max Nikulin
2022-06-20 12:10                                   ` Ihor Radchenko
2022-06-20 17:24                                     ` Max Nikulin
2022-06-21  4:07                                       ` Ihor Radchenko
2022-06-21  7:38                                         ` Arthur Miller
2022-06-21 15:48                                         ` Max Nikulin
2022-06-22 12:13                                           ` Arthur Miller
2022-06-22 16:29                                             ` Max Nikulin
2022-06-26  4:50                                               ` Arthur Miller
2022-06-29 17:02                                                 ` Max Nikulin
2022-06-30 23:30                                                   ` Arthur Miller
2022-07-01 15:53                                                     ` Proposal: 'executable' org-capture-templates Max Nikulin
2022-06-25  7:32                                             ` Proposal: 'executable' org-capture-templaes Ihor Radchenko
2022-06-26  4:25                                               ` Arthur Miller
2022-06-26  4:37                                                 ` Ihor Radchenko
2022-06-26  4:52                                                   ` Arthur Miller
2022-06-21  7:37                                       ` Arthur Miller
2022-07-02 11:31                                         ` Max Nikulin
2022-07-03 15:12                                           ` Arthur Miller
2022-07-07 16:14                                             ` Proposal: 'executable' org-capture-templates Max Nikulin
2022-06-18 15:05                               ` Proposal: 'executable' org-capture-templaes Arthur Miller
2022-06-19 10:53                                 ` Max Nikulin [this message]
2022-06-19 15:34                                   ` Arthur Miller
2022-07-03  3:32                                     ` Max Nikulin
2022-06-08 12:35                     ` Ihor Radchenko
2022-05-31 16:37         ` Max Nikulin
2022-06-01  1:45           ` arthur miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='t8mv7l$qk4$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).