From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Noah Lavine <noah549@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Key Mapping Proposal
Date: Sat, 16 Jan 2010 17:17:42 +0900 [thread overview]
Message-ID: <87y6jyo449.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <16d22e431001151603i5d2fab77u4f3054bb7e708323@mail.gmail.com>
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 8:17 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 [this message]
2010-01-16 18:41 ` Noah Lavine
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=87y6jyo449.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=emacs-devel@gnu.org \
--cc=noah549@gmail.com \
/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.