From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.emacs.devel Subject: Re: Key Mapping Proposal Date: Sat, 16 Jan 2010 13:41:51 -0500 Message-ID: <16d22e431001161041v2adb2ec9odd6ee6f5b528d78c@mail.gmail.com> References: <16d22e431001151603i5d2fab77u4f3054bb7e708323@mail.gmail.com> <87y6jyo449.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1263673164 10400 80.91.229.12 (16 Jan 2010 20:19:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Jan 2010 20:19:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 16 21:19:16 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NWF73-0002Qn-Gc for ged-emacs-devel@m.gmane.org; Sat, 16 Jan 2010 21:19:13 +0100 Original-Received: from localhost ([127.0.0.1]:33407 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWF73-0007FS-GQ for ged-emacs-devel@m.gmane.org; Sat, 16 Jan 2010 15:19:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NWDau-0000pb-Ur for emacs-devel@gnu.org; Sat, 16 Jan 2010 13:41:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NWDaq-0000pG-DS for emacs-devel@gnu.org; Sat, 16 Jan 2010 13:41:56 -0500 Original-Received: from [199.232.76.173] (port=60347 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWDaq-0000pD-AK for emacs-devel@gnu.org; Sat, 16 Jan 2010 13:41:52 -0500 Original-Received: from mail-yx0-f191.google.com ([209.85.210.191]:44886) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NWDap-0000gl-W9 for emacs-devel@gnu.org; Sat, 16 Jan 2010 13:41:52 -0500 Original-Received: by yxe29 with SMTP id 29so3702646yxe.14 for ; Sat, 16 Jan 2010 10:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hKE3RzP/drAHIjDx7loh7uyON36lyRz7N5ynZonOrz8=; b=grQWdSlmJkB0KEbJzimuuxPB+tNg30oI54xc71JmZWcvIkJtYbdY0W+bSk2V8MDyUZ ofjxnOaBanlVgjmLkckFqq4givULApE5uOtIxP+IDXQbJJwAt119Ug1/LKk0TY97RbtZ nN6olCkOP+VbDY8VNCJKqz+KDie4MKQZiyItw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VawR8p1zw/IGokoS5upp+XMQev5ds54xYG2aJ4kuEuWc/eRX72Qa8IUDYNQBFyB8RZ wR3fmng/YpAteK/Fx7Nc6DLONyIYJxr/R/+rlufvy8M+eWNV+vX49TAchwHldwDf8mEg HZH17k6FUrPVouWqtsIdDxfksqOLMWZ18TA7I= Original-Received: by 10.101.156.1 with SMTP id i1mr6692938ano.144.1263667311372; Sat, 16 Jan 2010 10:41:51 -0800 (PST) In-Reply-To: <87y6jyo449.fsf@uwakimon.sk.tsukuba.ac.jp> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Sat, 16 Jan 2010 15:19:05 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:120120 Archived-At: 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 w= rote: > Noah Lavine writes: > > =A0> Right now, as far as I can tell, each mode defines some functions an= d > =A0> then binds the appropriate keys to them. There are certain keys that > =A0> have conventional meanings, so "C-f" means forward even if you're in > =A0> picture-mode, and so on, and modes all try to respect this. The > =A0> problem comes if you want to change the meaning of not just one key > =A0> sequence, but the convention. Some people might like to use C-f, C-d= , > =A0> C-s, and C-e to move forward, down, back and up, because they're rig= ht > =A0> next to each other. In order to achieve this now, you would need to > =A0> rebind those keys in each mode that you use. > > You misunderstand. =A0Emacs keymaps are a layered architecture. =A0There > is a global keymap, where common functionality like motion commands > are bound to keys. =A0Of course different modes may have different > notions of concepts like "word" or "defun". =A0These 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). =A0Thus 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. =A0This > keymap is consulted *before* the global keymap, so you have to avoid > shadowing functionality the mode needs. =A0There 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. =A0These rebindings are shared by all the > specialized editor modes like text-mode, CC mode, and Lisp interaction > mode, without any change. =A0You would probably profit from studying the > implementation of CUA mode, and how it interacts with other keymapping > constraints. > > =A0> One issue that might occur is if the user's bindings for a > =A0> conventional key conflict with a binding unique to one particular > =A0> major mode. You'd want a system for bouncing the other bindings arou= nd > =A0> to prevent this, perhaps by keeping a list of unbound keys and then > =A0> 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. > >