Re-use keymap (for special modes)

[psionic-k]

IIRC magit still binds the status buffer independently from the transient definition even though it's mostly the same.

I'm writing some code that goes like this:

(transient-define-prefix uni-dyn-dispatch
  "Control the uni-dyn render states."
  ["Dynaverse\n"
   ["Rendering"
    ("c" "create" undefined :transient t)
    ("p" "pause" undefined :transient t)
    ("k" "clear data" undefined :transient t)
    ("g" "refresh size" undefined :transient t) ; todo add to keymap
    ("f" "fullscreen" uni-dyn-fullscreen)
    ""
    ("q" "quit" undefined :transient t)]
   ["Update Dynamics\n"
    ("l" "iteration limit" uni-dyn--dispatch-set-limit)
    ("p" "sampling scale" uni-dyn--dispatch-set-sampling-scale)
    ""
    ("e" "render escapers only" undefined :transient t)
    ("r" "render repeaters only" undefined :transient t)]
   ["" ("h" "toggle help" transient-quit-all)]])

(defvar uni-dyn-render-mode-map
  (let ((map (make-composed-keymap button-buffer-map special-mode-map)))
    (define-key map "c" #'undefined)
    (define-key map "k" #'undefined)
    (define-key map "g" #'undefined)
    (define-key map "q" #'undefined)
    (define-key map "h" #'uni-dyn-dispatch)

    (define-key map "l" #'uni-dyn-set-limit)
    (define-key map "g" nil) ; there is no update.
    map))

And whenever making special modes like this, it would be beneficial to extract the prefix's map (which has a superset of keymap information) and then modify the keymap for any commands that shouldn't be bound.

What concerns should come up during the implementation? Since a regular keymap is usually not dynamic like transients are during each setup, I believe logic that deactivates keys situationally for the transient UI should be bypassed, meaning a special mode map derived from a transient always has the full set of keys bound and nothing hidden / inapt.

[tarsius]

And whenever making special modes like this, it would be beneficial to extract the prefix's map (which has a superset of keymap information) and then modify the keymap for any commands that shouldn't be bound.

I am planing to eventually do something along those lines, but I would probably go the other way. I.e., add a :keymap argument to the prefix and allow suffixes to have no key defined. The key binding would then be looked up in the specified keymap.

One potential benefit of that approach could be that the binding could be changed using keymap-set/define-key instead of the less familiar transient-specific functions. However the main benefit I see and my motivation for adding such a feature, is that it would allow defining prefixes that just show information about the bindings that are available in the currently active keymaps, using transient's buffer. Think which-key but with the added benefit that related commands could be grouped instead of just showing an alphabetic list.

[psionic-k]

probably go the other way

Sounds good. The transient spec would just need to map commands to descriptions.

A modification mechanism for the transient's spec will need to exist might be useful, something more high-level than transient-insert-suffix Would be nice if the modification expressions are very similar to the original declaration expressions, a merging declaration style. I agree, just update the keymap 🐱

Personally I would prefer certain keys sequences never to be bound. I think it's unlikely that people will want to use long sequences in a modal dialog, and that means transient might also have a need for reducing key sequences while also avoiding ones the user hates. Whether independent or not, I sense a need for mass keymap re-writing, automatic keymap munging.

edit: abandoned ideas deemed inaccurate

I was going to work on an automated special mode adapter a while back but realized that automatically generating these mappings didn't seem viable for enough situations. With something like dired that has functionality that would be put into sub-prefixes by a human, it is instead all bound at the top level and users rely on extensive memory and familiarity with similar patterns of command bindings. An adapter cannot be both so simple and good.