Re: Key bindings proposal

[Stefan Monnier]

> If Emacs did take key binding customization seriously, it would have
> provided a whole bunch of *declarative* methods for specifying key
> bindings, along with rules for how they override each other or not
> override, as the need may be.

I understand what you want.  But, I'm not 100% sure what a good solution
would look like, and I'm even less clear on how we could get to such
a solution starting from Emacs's current system.

The main problem is not whether the method is declarative or not, but
rather the problem is to make intentions clear.

The issue with "intentions" is typically along the lines of "do you want
to bind `foo' to C-x C-x or do you want to bind it to the C-x key within
the main prefix keymap, or do you want to bind it to the repetition of
the key-sequence to which this main keymap is bound, or maybe only to
the repetition of just the last key in this key-sequence, or maybe to
the repetition of C-"the key above my "alt" key, or maybe you want to
bind it to whichever key `foobar' is bound in such-and-such-mode, ..."

If all Emacs packages could replace their `define-key' calls by others
that make the intentions clear, then it would be a lot easier/cleaner to
redefine key-bindings.

But if you look at the average quality of Elisp code, you'll quickly
learn that most authors have much better things to do than to worry
about such problems (i.e. their main worry is to get it to work for
the very specific Emacs they're currently using, with their current
.emacs).

Using `remap' is one way to express such an intention.
I would welcome patches that try to make intentions more clear
(e.g. eliminate the massive hardcoding of the "C-c" prefix all over the
place) and have myself replaced bindings to TAB and to M-q many times by
settings of indent-line-function and fill-paragraph-functions.  We can
keep improving in that direction, but the important part is that such
changes should be made in such a way that it's easy for coder to follow
the new style (ideally: easier than using the old inflexible style).

> it would go and compile the key bindings from all the sources, detect
> conflicts if necessary, and install the right set.

That's yet more difficult.  It means that the author and/or the user
needs to explicitly indicate when something should take precedence over
something else, and when not.  In most cases I know of, this tends to be
too heavy to use and instead the system is designed to use a default
precedence scheme (witness the "use first matching pattern" rule in
ML-style or Prolog pattern matching).
So I'd expect "conflict detection" to come with a lot of user complaints
(already we have occasional bug-reports about the errors signaled by
define-key when you define a binding for C-a C-b when C-a is already bound
to a command).


        Stefan