From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: Key Mapping Proposal Date: Sat, 16 Jan 2010 09:22:40 -0500 Message-ID: <4B51CBB0.3010204@siege-engine.com> References: <16d22e431001151603i5d2fab77u4f3054bb7e708323@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1263651765 11941 80.91.229.12 (16 Jan 2010 14:22:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Jan 2010 14:22:45 +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 15:22:37 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 1NW9Xv-0006qA-FN for ged-emacs-devel@m.gmane.org; Sat, 16 Jan 2010 15:22:35 +0100 Original-Received: from localhost ([127.0.0.1]:48093 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NW9Xw-0006qe-2H for ged-emacs-devel@m.gmane.org; Sat, 16 Jan 2010 09:22:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NW9Xo-0006qW-Lc for emacs-devel@gnu.org; Sat, 16 Jan 2010 09:22:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NW9Xn-0006q7-RL for emacs-devel@gnu.org; Sat, 16 Jan 2010 09:22:28 -0500 Original-Received: from [199.232.76.173] (port=53738 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NW9Xn-0006px-E5 for emacs-devel@gnu.org; Sat, 16 Jan 2010 09:22:27 -0500 Original-Received: from bird.interbax.net ([75.126.100.114]:56958) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NW9Xn-0005gh-5s for emacs-devel@gnu.org; Sat, 16 Jan 2010 09:22:27 -0500 Original-Received: (qmail 21074 invoked from network); 16 Jan 2010 08:22:24 -0600 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net (HELO ?192.168.1.201?) (71.184.83.10) by interbax.net with SMTP; 16 Jan 2010 08:22:24 -0600 User-Agent: Thunderbird 2.0.0.23 (X11/20090817) In-Reply-To: <16d22e431001151603i5d2fab77u4f3054bb7e708323@mail.gmail.com> X-detected-operating-system: by monty-python.gnu.org: Windows 98 (1) 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:120110 Archived-At: 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 > > >