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

[Max Nikulin <manikulin@gmail.com>]

On 22/06/2022 19:13, Arthur Miller wrote:
> Max Nikulin writes:
> 
> Menu should and application should be separated in my eyes. Menu is just a
> graphical/audio? presentation of selectable choice to the user. As such it
> should display choices, let user pick a choice, and return to the application
> the picked choice. Compare to completing-read, or org-mks. I don't think we
> should mingle application states and menu states.

By state I mean some structure opaque to menu package. It just receives 
it from caller as an optional argument and (when given) later passes it 
to handler. Maybe it is alien approach in LISP, but in C (where closures 
are impossible) it is a widely used technique. Functions having callback 
argument usually have another void* one that is later passed as an 
argument of the callback function in addition to other data.

(org-buffer-menu
  '(("a" "Option A" (1))
    ("b" "Option B" (2)))
  :handler
  (lambda (entry state)
   (message "value %S state %S" (nth 2 entry) state))
  :state
  '(1 2 3))

Menu caller does not care whether some buffer is created to present 
menu. Menu has no idea what state may contain, it just passes it to the 
handler. When menu is implemented as a buffer with keymap then state is 
stored as a buffer-local variable.

As to your current implementation of org-select, I do not like that it 
is responsibility of caller to create different buffer names to enable 
multiple instances of menu. I would prefer to control single/multiple 
instances through a boolean argument of org-select.

Arthur, I see that I should response to more your comments. However I am 
unable to identify source of disagreement, likely it is some different 
assumptions. That is why I decided to concentrate on a couple of 
questions in this message.