Stefan Monnier writes:
The main problem is not whether the method is declarative or not, but
rather the problem is to make intentions clear.
The reason for asking for declarative methods is that they are easier
for users and/or third-party customizers to deal with. The
whac-a-mole effect is hard enough for them to address. Side-effects
would introduce unseen interactions which would make it even harder to
figure out what is going on.
The way X windows deals with X resources is a perfectly fine way to
provide customization information. I don't see why we can't duplicate
that in Emacs.
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.
It is laudable goal, but I think it may be way too ambitious. If you
can try and do it for one mode out there and demonstrate how it can be
done, then we could make some progress.
But I have a feeling that we have the key binding stuff blown way out
of proportion. When RMS started Gnu Emacs, he seemed to have a clear
sense that the most important and frequently used functions would be
bound to keys, the rest would be done using M-x. But that idea is
totally lost now. Most Emacs coders today seem to think that every
function has to be on a key or people won't use it. And the key
combinations keep getting weirder and weirder. Like M-s a C-s to do
an isearch!
It would be a good idea for us to question ourselves why we are so
obsessed with key bindings whereas the rest of the world gets by
perfectly fine with very few key bindings. Here are two answers that
come to my mind (and perhaps there are others).
- In most modern OS's, one can navigate menus with keys. Emacs
doesn't use this mode of usage at all. The menu items don't have key
strokes associated with them, and the menus look totally
disorganized. In principle, this can give us much more "real estate"
to work with, without having to memorize arcane key bindings that make
our fingers twist.
- We have totally ignored the potential of command names.
I can type
`M-x isearch' a lot faster than I can type `M-s a C-s', but the later
is supposed to a holy cow whereas "isearch" doesn't exist as a
concept. Why can't we have two name spaces of global commands and
local commands, and bind them to functions?
I am not digressing. If we can start exploring some of these other
options, they can reduce the burden that the key bindings are having
to carry at the moment.
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).
Then let us discourage them from binding too many keys, and leave it
to the users to bind their own keys. There is only a limited amount
of key space out there! The predefined key bindings are even
defeating the remap-bindings as we have just discovered.
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).
My feeling is that, if we have a decent infrastructure for developing
and exchanging keymaps, people will do the work for themselves. (I
recall that when X Windows first started, people found it to be a
nightmare to customize them. But, very quickly, people started
writing .Xdefaults files and exchanging them and the knowhow spread
around. We can ask ourselves why people find it so much harder to do
keymaps as compared to Xdefaults.)
I guess we will discover what precedence rules are needed as we play
with these features. For instance, it would have been much nicer if
remap had precedence over the hard-coded bindings whereas it is the
other way around at present. I think it would be best if the user can
say which way the precedence should go.
I will continue playing with the features you mentioned and see how
well they work.
Cheers,
Uday