Guidance on Dynamically Generating Sub-menus

[kickingvegas]

Asking for guidance on how one could dynamically generate sub-menus using Transient. Solving this would enable an Transient-based implementation of the org-capture command.

In particular if the variable org-capture-template is configured so that keys are two or more characters are specified, then a sub-menu is generated.

keys         The keys that will select the template, as a string, characters
             only, for example "a" for a template to be selected with a
             single key, or "bt" for selection with two keys.  When using
             several keys, keys using the same prefix key must be together
             in the list and preceded by a 2-element entry explaining the
             prefix key, for example

                     ("b" "Templates for marking stuff to buy")

             The "C" key is used by default for quick access to the
             customization of the template variable.  But if you want to use
             that key for a template, you can.

Drawing from the example provided in transient-showcase, I was able to get this simple example code working for one level of dynamic menu generation. It is not clear to me what direction should be taken to extend this to support sub-menus.

(transient-define-prefix cc/dummy-prefix ()
  "Placeholder prefix to support dynamic Transient menu generation."
  [])

(setq cc/temp-data
      (list
       '("a" "A" (lambda ()
                   (interactive)
                   (message "A okay!")))

       '("b" "B" (lambda ()
                   (interactive)
                   (message "B okay!")))
       ))

(defun cc/option-generator (items)
  (mapcar (lambda (x)
            (transient-parse-suffix
             #'cc/dummy-prefix
             x))
          items))

(transient-define-prefix cc/tsc-generated-child ()
  "Prefix that uses `setup-children' to generate single child."

  ["Dynamic Menu Example"
   :setup-children
   (lambda (_)
     (cc/option-generator cc/temp-data))])

Would appreciate any input on this matter.

Thanks!

[tarsius]

What exactly did you have in mind with "sub-menus"?

Here's some ways this could be done (though not all of that is actually supported yet).

org-export-dispatch, as-is:

[C-b] Body only:    Off           [C-v] Visible only:     Off
[C-s] Export scope: Buffer        [C-f] Force publishing: Off
[C-a] Async export: Off


[h] Export to HTML
    [H] As HTML buffer            [h] As HTML file
    [o] As HTML file and open     

[i] Export to Texinfo
    [t] As TEXI file              [i] As INFO file
    [o] As INFO file and open     

[l] Export to LaTeX
    [L] As LaTeX buffer           [l] As LaTeX file
    [p] As PDF file               [o] As PDF file and open

[t] Export to Plain Text
    [A] As ASCII buffer           [a] As ASCII file
    [L] As Latin1 buffer          [l] As Latin1 file
    [U] As UTF-8 buffer           [u] As UTF-8 file

[P] Publish
    [f] Current file              [p] Current project
    [x] Choose project            [a] All projects


[&] Export stack                  [#] Insert template
[q] Exit

Most faithful port, which doesn't need any new functionality in Transient, would look like:

[C-b] Body only:    Off           [C-v] Visible only:     Off
[C-s] Export scope: Buffer        [C-f] Force publishing: Off
[C-a] Async export: Off


Export to HTML
[h H] As HTML buffer              [h h] As HTML file
[h o] As HTML file and open     

Export to Texinfo
[i t] As TEXI file                [i i] As INFO file
[i o] As INFO file and open     

Export to LaTeX
[l L] As LaTeX buffer             [l l] As LaTeX file
[l p] As PDF file                 [l o] As PDF file and open

Export to Plain Text
[t A] As ASCII buffer             [t a] As ASCII file
[t L] As Latin1 buffer            [t l] As Latin1 file
[t U] As UTF-8 buffer             [t u] As UTF-8 file

Publish
[P f] Current file                [P p] Current project
[P x] Choose project              [P a] All projects


[&] Export stack                  [#] Insert template
[q] Exit

Or maybe you want real "submenus", starting with a "topmenu" like

[C-b] Body only:    Off           [C-v] Visible only:     Off
[C-s] Export scope: Buffer        [C-f] Force publishing: Off
[C-a] Async export: Off

[h] Export to HTML
[i] Export to Texinfo
[l] Export to LaTeX
[t] Export to Plain Text
[P] Publish

[&] Export stack                  [#] Insert template
[q] Exit

and then after typing h show the submenu

Export to HTML
[H] As HTML buffer
[h] As HTML file
[o] As HTML file and open

Or the "as ..." commands could be hidden, similar to how the "common commands" are hidden in all menus, until the common prefix C-x is typed. But in this case we would want something representing the common prefix (or rather prefixes) to be shown.

Starting with a menu looking like the one in the previous variant, and also after typing h, it would look like this:

[C-b] Body only:    Off           [C-v] Visible only:     Off
[C-s] Export scope: Buffer        [C-f] Force publishing: Off
[C-a] Async export: Off

[h] Export to HTML
[h H] As HTML buffer
[h o] As HTML file and open 
[h h] As HTML file

[i] Export to Texinfo
[l] Export to LaTeX
[t] Export to Plain Text
[P] Publish

[&] Export stack                  [#] Insert template
[q] Exit

[kickingvegas]

Thanks for the response!

I was actually thinking more in line with sub-menus being “real menus” (implemented as prefixes). For example using org-export-dispatch, the abbreviated top level menu would look like:

[h] Export to HTML›
[i] Export to Texinfo›
[l] Export to LaTeX›

Selecting [h] would raise another prefix:

[H] As HTML Buffer             [h] As HTML file
[o] As HTML file and open

Arguably the sub-menu could support groups to support the layout above.

IMHO, the flattened menu example doesn’t provide any benefit over the current Org implementation. I’d argue that sub-menus offer the benefit of constraining user focus to choices that are available as the user makes decisions.

[tarsius]

I was actually thinking more in line with sub-menus being “real menus” (implemented as prefixes).

So my second alternative.

Your question then is "how can I dynamically define prefix commands?", I suppose.

You shouldn't do that, not in :setup-children, or elsewhere. Probably.

emoji-insert used to do that, before I refactored it. The new implementation does not dynamically define new commands, instead it binds the same pre-defined commands many times and makes each instance behave differently by using a different value for the :scope in the dynamically generated binding as suffix. (And that recursively, which won't be necessary here.)

In this case you probably would only want all the "Export to X" sub-prefix commands to be just one command. The "As Y" suffixes should probably be the existing org-*-export-as-* commands.

This might be an implementation strategy worth pursuing; but if it really is appropriate here, I can't tell without actually trying to implement it myself. (Which I was planning to do eventually, but not now.)

Regardless, you might find it interesting to study emoji-insert.