[Top][All Lists]

[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, 3 Jul 2022 10:32:16 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

On 19/06/2022 22:34, Arthur Miller wrote:
Max Nikulin writes:
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.

That sounds like a new feature. You are correct, keymaps do open in that
direction. That would be possible to tuck on the routine that saves the
temporary buffer (whatever is called with C-c C-c). When user press C-c C-c in a
capture buffer, that is the only time when interaction with real a file on the
disk happends, right?

I am going through older messages trying to find possible sources of different assumptions. I am at least partially repeating myself, but I consider this point as an important one.

When a capture template is selected, `org-capture-fill-template' adds capture text to the proper heading of the target document. Capture windows display narrowed down buffers of target documents. Disk operations happen on C-c C-s hit by user (it can be done for a capture buffer as well) or on autosave timer. Aborting capture by C-c C-k reverts the change by erasing earlier added text from the target document. It is safe to have multiple capture buffers, but some amount of work is required to make parallel menu buffers straightforward.

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.

I don't think it matters there that completing read is blocking. Users do
completing read just to pick one action to get executed. I don't think I
understand how qeue of captures to do would work, to be honest.

It is related to code calling menu rather than implementation of menu. It is a way to improve handling of parallel capture template selection menus even with `org-mks'. Certainly I expect that new menu library will not add any new obstacles. Assume a modal template selection is configured, e.g. based on completing read and such "menu" is currently active. The user may switch to another application and request new capture through "org-protocol:" URI. The best way to handle such case from my point of view is to detect that the menu is active, collect values necessary to expand template and put this capture state to some queue. As soon as the user selects template for the capture started earlier, next state is popped from the queue and next template selection prompt is activated.

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

I am not sure what do you bring that cod up? I looked at the link, but I just
see text styling with faces. Do  you mean to use text properties to communicate
the state? Sure text properties can be used for different things, but already
have "template" (a list) we are passing around. Isn't it sufficient as a state
carrier. You can push/pop things off of it to communicate whatever. Forgive me
if I don't understand what you meant there.

At that moment I considered it as a feature request to add text properties to keys displayed in the menu. Later I realized that it is not a problem even for `org-mks' since strings with keys may be propertized in advance.

It is unrelated to user state, but the patch adds another implementation of menu. I hope that it will be possible to avoid dedicated menu code for this particular query and rely on org-select your proposed.

Timothy wrote that a reason for custom menu was modal nature of `org-mks', so it would made impossible to inspect the document before decision if a remote URL should be allowed. org-select should relieve this limitation.

reply via email to

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