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

[Max Nikulin <manikulin@gmail.com>]

On 05/06/2022 22:07, Arthur Miller wrote:
> Max Nikulin writes:
> 
> After input from Ihor I agree that it isn't the best way, and was
> able to refactor org-mks to create a menu where I can execute any lisp form,
> when it comes in a list like this : ("h" "hello-word" (message "Hello,
> World")), where third element is just a lisp form. I have something like this:

This message is merely my opinion that you may disagree. I am not trying 
to prevent you from going forward.

 From my point of view current `org-mks' is more general giving you 
opportunity to treat extra elements as you wish. A thin wrapper allows 
to evaluate 3rd element of returned list. You have not convinced me that 
built-in executable form is the essential feature.

> (defun demo3 ()
>    "Illustrate nested menus, unicode separator and alternative decorator."
>    (interactive)
>    (let ((quick-menu-key-decorator-chars "<>")
>          (quick-menu-vertical-separator ?─))
>      (quick-menu
>       ;; table
>       '(("g" "Greetings")
>         ("gh" "Hello, World!" (message "Hello, World!"))
>         ("gb" "Bar" (message "Hello, Bar!")))
>       ;; description
>       nil
>       ;; more tables
>       '(("f" "Functions")
>         ("ff" "Find File" (call-interactively #'find-file))
>         ("fo" "Open File" (flet ((next-read-file-uses-dialog-p () t))
>                             (call-interactively 'find-file))))
>       '(("q" "Abort" (user-error "Abort"))))))

It is tightly based on org-mks, but actually it is way to represent list 
of choices with some hints to possible hierarchy and accelerator keys. 
Quite similar list may be fed to completion read or represented as a 
hierarchical GUI menu. The only specific is "always visible" elements 
like "abort". When Ubuntu used Unity desktop their had a nice feature of 
searching in application menu.

There should be an extension point that allows users to replace 
representation e.g. to improve accessibility.

> DESCRIPTON is a property list containing following members:
...
> :horizontal    when `t', if multiple menus are present they are rendered from
> left to right, otherwise from top to bottom.

It may depend on whether a window created to display menu is tall and 
narrow or wide.

> I have paramterized decorator character for shortcut keys as they appear in the
> buffer, org-capture uses "[]", as well as menu separator, which is currently
> hard-coded in org-capture,

I agree that org-mks may have additional argument to specify menu 
decoration.

> Exactly.  It is important that org-capture is one capture at the time so people
> don't mess their note files, agenda files etc.
> 
>>                                                          Unsure if some
>> intermediate persistent store would be an improvement.
> 
> Not sure what you mean here, but I don't plan to change anything in org-capture
> itself, it should still be one-task at the time.

Changing interface to less degree of blocking may be confusing for 
users. Capture template selection menu may be displayed in another frame 
hidden behind other application, on another monitor, on another virtual 
desktop, so invisible. So a user earlier distracted by something urgent 
may try to start another capture. Captures may be initiated from other 
applications using org-protocol.

To avoid data loss while other capture is in progress, the data of next 
capture may be temporary saved to some place till the user pops it from 
the queue. I mentioned persistence since something may unexpectedly 
crash, so it should be possible to resurrect enqueued captures in next 
Emacs session.

>> Likely nobody performed any steps toward `transient' as the interface, but due
>> to such requests it would be nice to have possibility to switch between menu
>> implementations.
> 
> I am not building some generalized framework, as I said in my first respone to
> Ihor :-).

I am not requesting for a framework, I mean API compatible with other 
frameworks to let user choose their preferred ones.

So tunables to control decoration sounds interesting. I am in doubts 
concerning fixing some element as executable. Mode-map instead of 
minibuffer may be a great step to more convenient interface (it 
resembles help buffers), but may require more changes in functions that 
do actual job. From other messages on this list my impression is that 
API should be designed having in mind flexibility and other UI packages.