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