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

Stefan Monnier <[email protected]> writes:

> BTW, two things I wonder about the overall design:
>
> - Do we want to "merge" two different keymap bindings (say we have
>   a metafunction bound to TAB in the global map and another metafunction
>   bound to TAB in the local map), or do we want to force the use of the
>   hook as the only way to multiplex a single key?

I think it will make sense to merge, yes.
Similar to how the higher-priority keymap without a given key bound
passes the control down to next keymap, we can generalize that
conditional binding in previous keymap, if does not match, passes the
control down to next keymap in the order.

If someone needs to explicitly make "no condition matches -> do nothing"
binding, it can always be done with something like

(keymap-dynamic-bind ...
  (:doc "...")
  <conditions>
  (:default #'undefined))

> - If we evaluate the `:when` conditions during `access_keymap` (like we
>   currently do for `menu-item`), then we don't want to allow
>   side-effecting `:when`s, since those side-effects would be executed at
>   an inopportune time (e.g. before we set `this-command` and run
>   `pre-command-hook`).

Yes. This is the same as in menu-item.
We may additionally demand the :when to have 'side-effect-free declared explicitly.

> While sleeping I thought of the following:
>
> - Define some way to mark some commands as "metafunctions".
> - When we lookup a (list of) keymap(s) and the command we found is
>   marked as a "metafunction", we continue looking for further bindings
>   and return a composite command made up of the metafunctions (plus
>   potentially a final non-metafunction) found.

Could you provide an example? Your description is not entirely clear for me.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>