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.
