From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Key Mapping Proposal Date: Sat, 16 Jan 2010 17:17:42 +0900 Message-ID: <87y6jyo449.fsf@uwakimon.sk.tsukuba.ac.jp> References: <16d22e431001151603i5d2fab77u4f3054bb7e708323@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1263629398 21815 80.91.229.12 (16 Jan 2010 08:09:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Jan 2010 08:09:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Noah Lavine Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 16 09:09:50 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 1NW3jB-0001MG-7V for ged-emacs-devel@m.gmane.org; Sat, 16 Jan 2010 09:09:49 +0100 Original-Received: from localhost ([127.0.0.1]:43422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NW3jB-0002Yx-Ow for ged-emacs-devel@m.gmane.org; Sat, 16 Jan 2010 03:09:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NW3j4-0002X3-QO for emacs-devel@gnu.org; Sat, 16 Jan 2010 03:09:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NW3j0-0002UB-3Z for emacs-devel@gnu.org; Sat, 16 Jan 2010 03:09:42 -0500 Original-Received: from [199.232.76.173] (port=41579 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NW3iz-0002U2-Qj for emacs-devel@gnu.org; Sat, 16 Jan 2010 03:09:37 -0500 Original-Received: from mx20.gnu.org ([199.232.41.8]:64568) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NW3iw-0003cT-OO for emacs-devel@gnu.org; Sat, 16 Jan 2010 03:09:35 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NW3iv-0000d0-M4 for emacs-devel@gnu.org; Sat, 16 Jan 2010 03:09:34 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id D1FB51537B3; Sat, 16 Jan 2010 17:09:25 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 3F09B1A2A92; Sat, 16 Jan 2010 17:17:43 +0900 (JST) In-Reply-To: <16d22e431001151603i5d2fab77u4f3054bb7e708323@mail.gmail.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" a03421eb562b XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:120091 Archived-At: 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.