[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Key Mapping Proposal
From: |
Noah Lavine |
Subject: |
Re: Key Mapping Proposal |
Date: |
Sat, 16 Jan 2010 13:41:51 -0500 |
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 <address@hidden> 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.
>
>
- Key Mapping Proposal, Noah Lavine, 2010/01/16
- Re: Key Mapping Proposal, Fabian Ezequiel Gallina, 2010/01/16
- Key Mapping Proposal, Stephen J. Turnbull, 2010/01/16
- Re: Key Mapping Proposal,
Noah Lavine <=
- Re: Key Mapping Proposal, Teemu Likonen, 2010/01/16
- Re: Key Mapping Proposal, Eric M. Ludlam, 2010/01/16
- Re: Key Mapping Proposal, Stefan Monnier, 2010/01/16