Re: Key Mapping Proposal

[Noah Lavine <noah549@gmail.com>]

Ah, I see what you mean. If I understand correctly, keymaps bind key
sequences to particular cells, which are then rebound by different
modes.

As far as I can tell, your reply and Fabian Gallina's reply use the
same mechanism, and Eric Ludlow's might as well (I'm not sure what the
mode-local functionality is yet).

However, it seems like my question and Teemu Likonen's reply show that
the functionality isn't well enough documented yet. If people agree, I
would like to contribute a patch for the keybinding documentation in
the emacs manual to describe how to rebind keys in a way that updates
all modes. (When I first asked my question, most of what I knew came
from the emacs manual, and I had actually avoided rebinding keys
because I thought that I would inevitably rebind keys in some modes
but not all and then have horribly confusing keymaps to remember.)

I think a good solution would be an info node that explains this
mechanism which would be linked from the Customization->Key Bindings
node, with a list of the generic functions that are commonly the
target of keybindings, which seem to be the same as the
conventional-function storage locations in my original email. (I can
see that this might seem useless, because you could always find these
functions with C-h k, but I suspect that having a list around would be
useful for users and mode writers.) Does this seem like a good idea?

Thanks!
Noah Lavine

On Sat, Jan 16, 2010 at 3:17 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> 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.
>
>