Key Mapping Proposal

[Stephen J. Turnbull]

Noah Lavine writes:

 > Right now, as far as I can tell, each mode defines some functions and
 > then binds the appropriate keys to them. There are certain keys that
 > have conventional meanings, so "C-f" means forward even if you're in
 > picture-mode, and so on, and modes all try to respect this. The
 > problem comes if you want to change the meaning of not just one key
 > sequence, but the convention. Some people might like to use C-f, C-d,
 > C-s, and C-e to move forward, down, back and up, because they're right
 > next to each other. In order to achieve this now, you would need to
 > rebind those keys in each mode that you use.

You misunderstand.  Emacs keymaps are a layered architecture.  There
is a global keymap, where common functionality like motion commands
are bound to keys.  Of course different modes may have different
notions of concepts like "word" or "defun".  These are implemented by
writing the core functions to take account of the fact that different
modes may want somewhat different semantics (and in the case of defun
movement, a mode may define a completely different function, and if it
does, the defun movement function automatically calls it).  Thus for
movement commands you change their bindings only in one place, and all
modes get the benefit.

Mode-specific functionality is bound in a mode specific keymap.  This
keymap is consulted *before* the global keymap, so you have to avoid
shadowing functionality the mode needs.  There are conventions for
achieving this.

For example, another case of common functionality is copy/cut/paste;
there is a "CUA mode" which rebinds those functions to the C-c, C-x,
C-v keys that Windows users expect (and moves the original
functionality elsewhere.  These rebindings are shared by all the
specialized editor modes like text-mode, CC mode, and Lisp interaction
mode, without any change.  You would probably profit from studying the
implementation of CUA mode, and how it interacts with other keymapping
constraints.

 > One issue that might occur is if the user's bindings for a
 > conventional key conflict with a binding unique to one particular
 > major mode. You'd want a system for bouncing the other bindings around
 > to prevent this, perhaps by keeping a list of unbound keys and then
 > assigning the functions that need bindings to those keys one by one.

Such a user interface for keymap customization would indeed be useful,
but as you point out, it's not easy to design, let alone implement.