Re: On keybindings and the slow erosion of help's utility

> From: Ihor Radchenko <[email protected]>
> Cc: [email protected], [email protected], [email protected]
> Date: Sun, 02 Aug 2026 09:47:58 +0000
> 
> Eli Zaretskii <[email protected]> writes:
> 
> >> From: Ihor Radchenko <[email protected]>
> >> Cc: Eli Zaretskii <[email protected]>, [email protected], [email protected]
> >> Date: Sat, 01 Aug 2026 16:17:09 +0000
> >> 
> >> What I suggest is allowing the binding to be a new element that will
> >> determine what should be done by running Elisp code.
> >> Now, on M-w, that Elisp code will run and return nil, a command, a
> >> keymap, or keymap variable symbol - the same elements as allowed in the
> >> keymaps already.
> >> 
> >> This is the low-level structure.
> >> 
> >> Further, I propose to have a helper macro keymap-dynamic-bind that will
> >> allow defining these new dynamic bindings in useful ways.
> >> I propose that each dynamic binding can be something akin abnormal hook,
> >> where users can define a set of conditions that will run one or another
> >> command depending on the current context. The elements of this abnormal
> >> hook are delegated the job of deciding the dynamic binding - nil, a
> >> command, a keymap, or keymap variable.
> >
> > How is this different from binding to a command which does all this
> > dynamic stuff, including running a hook if needed?
> 
> The difference is that the "command" return value can resume the key
> lookup. If it returns nil, Emacs will continue key lookup in other
> keymaps. If it returns a keymap, Emacs will continue lookup in the
> returned keymap. Such things are currently not possible with command
> binding.

Sorry, I'm not following.  A command can definitely perform look up in
any keymaps it wants, and do whatever it wants with what it finds
there, including calling the bindings it finds there.  What are the
advantages of doing that under Emacs's control instead of under the
control of a command?