From: Noah Lavine <noah549@gmail.com>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: emacs-devel@gnu.org
Subject: Re: Key Mapping Proposal
Date: Sat, 16 Jan 2010 13:41:51 -0500 [thread overview]
Message-ID: <16d22e431001161041v2adb2ec9odd6ee6f5b528d78c@mail.gmail.com> (raw)
In-Reply-To: <87y6jyo449.fsf@uwakimon.sk.tsukuba.ac.jp>
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.
>
>
next prev parent reply other threads:[~2010-01-16 18:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-16 0:03 Key Mapping Proposal Noah Lavine
2010-01-16 7:57 ` Fabian Ezequiel Gallina
2010-01-16 8:17 ` Stephen J. Turnbull
2010-01-16 18:41 ` Noah Lavine [this message]
2010-01-17 5:49 ` Stephen J. Turnbull
2010-01-16 8:25 ` Teemu Likonen
2010-01-16 14:22 ` Eric M. Ludlam
2010-01-16 19:28 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16d22e431001161041v2adb2ec9odd6ee6f5b528d78c@mail.gmail.com \
--to=noah549@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=stephen@xemacs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.