Re: Delegating user-reserved key binding space definition to users

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Psionic K <psionik@positron.solutions>,  Emacs developers
>  <emacs-devel@gnu.org>
> Date: Mon, 28 Nov 2022 13:15:26 -0500
> 
> > Currently, the commands in major mods are bound to specific key
> > bindings. The bindings are chosen either arbitrarily, according to major
> > mode author preferences, or according to semi-established default key
> > binding scheme (like C-f/C-M-f/C-n/C-v/etc). Either way, trying to
> > re-bind commands in multiple major modes is not easy.
> 
> Yup.  I fully agree that it's a real problem.
> 
> I'd welcome a solution to it.  Even an "unrealistic" one would be good.
> Currently, I don't even know what a good solution could look like.
> 
> To me a solution should allow packages to declare that command FOO
> should be bound to some key based on SOME-INFO, such that it will be
> bound to one key in "normal Emacs mode", and to another in `evil-mode`
> and to yet another in `god-mode`, etc...
> 
> Some SOME-INFO needs to provide not a specific key, but some information
> from which we can compute the "natural key" that fits the keybinding
> style that the user selected.
> 
> Then there are also the issues of overloading several operations on
> a single key (like TAB).  So far we've solved this along the lines you
> suggest (a "generalized command", such as `indent-for-tab-command`), and
> maybe that's good enough for this, tho it prevents changing this
> overloading according to the keybinding style.
> 
> [ BTW, another way to look at it is not "how can we compute which key to
>   bind FOO to" but rather "how can we compute which command to run when
>   KEY is hit".  IOW, we could make keymaps more dynamic such that when
>   you hit KEY, Emacs passes that to a "procedural keymap" which will
>   *compute* (rather than lookup) which command to run, according to the
>   current keybinding style.
>   Not sure it would be better: I just mention it as one of the many
>   things that we may want to consider in order to find a good solution
>   to the problem.  ]

How about adding this (and more) to etc/TODO?