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

[Max Nikulin <manikulin@gmail.com>]

On 21/06/2022 11:07, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
> The other question is altering the org-capture code.
> I think that it is too early to discuss org-capture part just yet.
> Lets first finalize the generic library itself and discuss the
> appropriate adjustments to
> org-capture/org-agenda/org-export/org-todo/etc code later.

 From my point of view changing menu without adjusting calling logic is 
a kind of trade-off with uncertain net result. New UI may significantly 
affect different user expectations. It seems this is the point of our 
disagreement. You tend to consider menu in isolation trying to postpone 
the question concerning interaction of code running before menu creation 
and handlers of menu items (they are not belong to the same call stack 
any more).

What I am really afraid is words like:

> Sure. That somewhere can be buffer-local variable inside the capture
> menu buffer. Or global variable. Or closure. How is it relevant to the
> capture menu?

I am trying to avoid implementation of menu that would make passing 
state to handlers unreliable or prohibitively complicated.

Global variables are certainly not an option because such approach does 
not allow several instances of menu created in parallel.

To use buffer-local variables some support from the side of menu library 
is required. Buffer does not exist when menu function is called. So 
either some callback should be passed to menu to be invoked when a new 
buffer is created for menu or that buffer should be returned from the 
menu creating function. Unsure if (current-buffer) would be a reliable 
approach.

Closures should work, but would be it convenient enough?

Maybe some intermediate layer should be introduced to make alternative 
implementation of menu (transient, completing read, etc.) easier.

I believe, discussing design of menu without evaluation if it is 
suitable to features that should use it (capture, agenda, etc.), there 
is a risk to create unreasonable restrictions on further steps.

That is why I consider the following aspects of menu design as essential 
ones:
- A clearly determined way to pass some state from a function that 
requests creation of menu to handlers of menu items.
- When a non-blocking technique to wait user decision is used, multiple 
instances of the same menu should be allowed.
- Defined extension points for alternative implementations to avoid code 
duplication and divergence of behavior.

My fear is that if such points are ignored in the beginning, it may 
become impossible later.