Key Mapping Proposal

Key Mapping Proposal

[Noah Lavine]

Dear emacs-devel,

I'd like to suggest a change to the way modes bind keys, to make it
easier for users to customize keys.

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. It seems like there
should be a better way.

My suggestion is this: have one location which stores the user's
keybinding for the "forward" key, whatever "forward" means for a
particular mode. Any given mode would then use this to bind their
particular "forward" function to whatever key the user wanted. Do the
same for other keys with conventional meaning, and then modify the
major modes to use these in their keybindings.

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.
This would give up the ability to give mnemonic key bindings to
functions, but the issue would only occur if the user was customizing
their keys, in which case it seems like the user's preferences should
take priority.

I'm happy to contribute work to this, but I wanted to ask emacs-devel
first to see if you were interested in this, and if so, what you
thought the right approach was.

Thank you
Noah Lavine

Re: Key Mapping Proposal

[Fabian Ezequiel Gallina]

2010/1/15 Noah Lavine <noah549@gmail.com>:
> Dear emacs-devel,
>
> I'd like to suggest a change to the way modes bind keys, to make it
> easier for users to customize keys.
>
> 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. It seems like there
> should be a better way.
>
> My suggestion is this: have one location which stores the user's
> keybinding for the "forward" key, whatever "forward" means for a
> particular mode. Any given mode would then use this to bind their
> particular "forward" function to whatever key the user wanted. Do the
> same for other keys with conventional meaning, and then modify the
> major modes to use these in their keybindings.
>
> 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.
> This would give up the ability to give mnemonic key bindings to
> functions, but the issue would only occur if the user was customizing
> their keys, in which case it seems like the user's preferences should
> take priority.
>
> I'm happy to contribute work to this, but I wanted to ask emacs-devel
> first to see if you were interested in this, and if so, what you
> thought the right approach was.
>
> Thank you
> Noah Lavine
>

I agree it is a good idea, my guess is that this could be achieved if
modes use `substitute-key-definition' to define analog commands for
standard commands (forward-char, backward-char, etc) like this:

(defvar my-mode-map
  (let ((my-mode-map (make-sparse-keymap)))
    (define-key my-mode-map "\C-ch" 'my-do-something)
    (substitute-key-definition 'forward-char 'my-forward-char
my-mode-map (current-global-map))))

This way if I rebind C-f (forward-char) to M-f globally this should
make M-f to call my-forward-char when i'm using my-mode.

(global-set-key (kbd "M-f") 'forward-char)

So my guess is that it is just a matter of fixing that on every mode
not using `substitute-key-definition' for standard commands.



Regards,
-- 
Fabián E. Gallina
http://www.from-the-cloud.com

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.

Re: Key Mapping Proposal

[Teemu Likonen]

On 2010-01-15 19:03 (-0500), Noah Lavine wrote:

> I'd like to suggest a change to the way modes bind keys, to make it
> easier for users to customize keys.

> My suggestion is this: have one location which stores the user's
> keybinding for the "forward" key, whatever "forward" means for a
> particular mode. Any given mode would then use this to bind their
> particular "forward" function to whatever key the user wanted. Do the
> same for other keys with conventional meaning, and then modify the
> major modes to use these in their keybindings.

I don't know how difficult and how much work this would be but as a user
I would like such feature very much. I faced a related problem with my
ergo-movement-mode [1] which, for example, uses

          i
    M-  j k l

keys for basic cursor movements. The mode actually doesn't bind them
directly but relatively. That is, M-l is bound to

    (lambda () (interactive)
      (call-interactively
       (key-binding "\C-f")))

so it executes whatever command is bound to C-f. This works in all major
modes automatically but the problem is that I can't rebind C-f to
anything. The default Emacs global keybindings are not practically
customizable.

---------------
 1. http://www.emacswiki.org/emacs/ErgoMovementMode

Re: Key Mapping Proposal

[Eric M. Ludlam]

Hi,

There is a different style of solution for the functions beginning/end 
of defun.  For beginning-of-defun, there is a 
beginning-of-defun-function.  The mode would then override the fcn, and 
not the keybinding at all.  If all 'classic' keybound fcns used this 
technique, then modes could override the functionality, and a user could 
override the global keybindings, and get what they want.

To plug my `mode-local' concept again, this tools is designed to make 
setting up something like beginning-of-defun-function declarative, 
instead of hand-written functional.  Using a common architecture for 
making functions overridable by mode would make it easier to hit all the 
common functions that might fall into this catagory.

I developed mode-local for CEDET/Semantic because so much of the 
parsing/analyzing architecture is mode specific.  The result is clean 
high-level code, and mode specific behaviors.

Eric

Noah Lavine wrote:
> Dear emacs-devel,
> 
> I'd like to suggest a change to the way modes bind keys, to make it
> easier for users to customize keys.
> 
> 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. It seems like there
> should be a better way.
> 
> My suggestion is this: have one location which stores the user's
> keybinding for the "forward" key, whatever "forward" means for a
> particular mode. Any given mode would then use this to bind their
> particular "forward" function to whatever key the user wanted. Do the
> same for other keys with conventional meaning, and then modify the
> major modes to use these in their keybindings.
> 
> 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.
> This would give up the ability to give mnemonic key bindings to
> functions, but the issue would only occur if the user was customizing
> their keys, in which case it seems like the user's preferences should
> take priority.
> 
> I'm happy to contribute work to this, but I wanted to ask emacs-devel
> first to see if you were interested in this, and if so, what you
> thought the right approach was.
> 
> Thank you
> Noah Lavine
> 
> 
> 

Re: Key Mapping Proposal

[Noah Lavine]

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.
>
>

Re: Key Mapping Proposal

[Stefan Monnier]

> My suggestion is this: have one location which stores the user's
> keybinding for the "forward" key, whatever "forward" means for a
> particular mode. Any given mode would then use this to bind their

You can use "remap" for this.  It's pretty much exactly what it was
created for.


        Stefan

Re: Key Mapping Proposal

[Stephen J. Turnbull]

Noah Lavine writes:

 > However, it seems like my question and Teemu Likonen's reply show that
 > the functionality isn't well enough documented yet.

It is well documented I think, but in the Emacs-Lisp manual.

It's a matter of judgment (and mine doesn't really matter much on this
list :-), but IMHO it doesn't belong in the Emacs User manual.  Again
I commend to you the study of CUA mode, which has been endlessly
controversial (partly for reasons of free software advocacy, of
course, but also for technical reasons) exactly because trying to move
as few as four bindings forces changes throughout the keymap, and then
of course it encourages requests for more CUA compatibility, in mouse
gestures as well, etc.  IOW, any such change is equivalent in
difficulty to writing a simple major mode (and can be substantially
more difficult if you want to contribute it to the community, because
to get much uptake you need to compromise with others' "essential"
keybindings.

YMMV; I offer my opinion to give you an idea of what kind of contrary
opinion may be out there so you can deal with it in advance, not to
discourage you from trying.

 > 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,

Doing C-h b in *scratch* gives a pretty close approximation IMO.  Try
it and let us know.  Note that although the default global keymap is
one of the most stable features of the Emacs UI, it does change
occasionally.  Since Emacs is capable of generating it on the fly, I
think it's best to point to the functionality of C-h b rather than put
a table in the manual.

In addition, I would suggest a link to the node on keymaps in the
Emacs Lisp manual (which Emacs doesn't install by default, or maybe
that's just MacPorts, grr).

I think that what you'll find if you browse the help for help is that
most of the information you've mentioned is oly a few keystrokes away.
It would be useful to provide a summary of how to get the information
that you think is useful in the node in the Emacs User guide (although
I still think that the detailed information belongs in the Lisp
Reference).