From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Uday S Reddy Newsgroups: gmane.emacs.devel Subject: Re: Key bindings proposal Date: Thu, 29 Jul 2010 16:28:24 +0100 Message-ID: <19537.40472.267000.563053@gargle.gargle.HOWL> References: <19534.1494.627000.357123@gargle.gargle.HOWL> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1280418229 29182 80.91.229.12 (29 Jul 2010 15:43:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 29 Jul 2010 15:43:49 +0000 (UTC) Cc: Uday S Reddy , "Stephen J. Turnbull" , Teemu Likonen , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 29 17:43:47 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.69) (envelope-from ) id 1OeVGp-0004ZJ-J7 for ged-emacs-devel@m.gmane.org; Thu, 29 Jul 2010 17:43:43 +0200 Original-Received: from localhost ([127.0.0.1]:48683 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OeV2T-0005GJ-Lw for ged-emacs-devel@m.gmane.org; Thu, 29 Jul 2010 11:28:53 -0400 Original-Received: from [140.186.70.92] (port=48948 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OeV2L-0005FB-Mg for emacs-devel@gnu.org; Thu, 29 Jul 2010 11:28:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OeV2I-0007I0-9C for emacs-devel@gnu.org; Thu, 29 Jul 2010 11:28:45 -0400 Original-Received: from sun61.bham.ac.uk ([147.188.128.150]:41269) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OeV2H-0007Hd-Uq for emacs-devel@gnu.org; Thu, 29 Jul 2010 11:28:42 -0400 Original-Received: from [147.188.128.127] (helo=bham.ac.uk) by sun61.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1OeV2E-0000WS-NM; Thu, 29 Jul 2010 16:28:38 +0100 Original-Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1OeV2E-0006QU-DS; Thu, 29 Jul 2010 16:28:38 +0100 Original-Received: from gromit.cs.bham.ac.uk ([147.188.193.16] helo=MARUTI.cs.bham.ac.uk) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1OeV2D-0000SX-TT; Thu, 29 Jul 2010 16:28:38 +0100 Original-Newsgroups: gmane.emacs.devel In-Reply-To: X-Mailer: VM 8.1.92a under 23.2.1 (i386-mingw-nt5.1.2600) X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:127966 Archived-At: Stefan Monnier writes: > The main problem is not whether the method is declarative or not, but > rather the problem is to make intentions clear. The reason for asking for declarative methods is that they are easier for users and/or third-party customizers to deal with. The whac-a-mole effect is hard enough for them to address. Side-effects would introduce unseen interactions which would make it even harder to figure out what is going on. The way X windows deals with X resources is a perfectly fine way to provide customization information. I don't see why we can't duplicate that in Emacs. > The issue with "intentions" is typically along the lines of "do you want > to bind `foo' to C-x C-x or do you want to bind it to the C-x key within > the main prefix keymap, or do you want to bind it to the repetition of > the key-sequence to which this main keymap is bound, or maybe only to > the repetition of just the last key in this key-sequence, or maybe to > the repetition of C-"the key above my "alt" key, or maybe you want to > bind it to whichever key `foobar' is bound in such-and-such-mode, ..." > > If all Emacs packages could replace their `define-key' calls by others > that make the intentions clear, then it would be a lot easier/cleaner to > redefine key-bindings. It is laudable goal, but I think it may be way too ambitious. If you can try and do it for one mode out there and demonstrate how it can be done, then we could make some progress. But I have a feeling that we have the key binding stuff blown way out of proportion. When RMS started Gnu Emacs, he seemed to have a clear sense that the most important and frequently used functions would be bound to keys, the rest would be done using M-x. But that idea is totally lost now. Most Emacs coders today seem to think that every function has to be on a key or people won't use it. And the key combinations keep getting weirder and weirder. Like M-s a C-s to do an isearch! It would be a good idea for us to question ourselves why we are so obsessed with key bindings whereas the rest of the world gets by perfectly fine with very few key bindings. Here are two answers that come to my mind (and perhaps there are others). - In most modern OS's, one can navigate menus with keys. Emacs doesn't use this mode of usage at all. The menu items don't have key strokes associated with them, and the menus look totally disorganized. In principle, this can give us much more "real estate" to work with, without having to memorize arcane key bindings that make our fingers twist. - We have totally ignored the potential of command names. I can type `M-x isearch' a lot faster than I can type `M-s a C-s', but the later is supposed to a holy cow whereas "isearch" doesn't exist as a concept. Why can't we have two name spaces of global commands and local commands, and bind them to functions? I am not digressing. If we can start exploring some of these other options, they can reduce the burden that the key bindings are having to carry at the moment. > But if you look at the average quality of Elisp code, you'll quickly > learn that most authors have much better things to do than to worry > about such problems (i.e. their main worry is to get it to work for > the very specific Emacs they're currently using, with their current > .emacs). Then let us discourage them from binding too many keys, and leave it to the users to bind their own keys. There is only a limited amount of key space out there! The predefined key bindings are even defeating the remap-bindings as we have just discovered. > That's yet more difficult. It means that the author and/or the user > needs to explicitly indicate when something should take precedence over > something else, and when not. In most cases I know of, this tends to be > too heavy to use and instead the system is designed to use a default > precedence scheme (witness the "use first matching pattern" rule in > ML-style or Prolog pattern matching). > So I'd expect "conflict detection" to come with a lot of user complaints > (already we have occasional bug-reports about the errors signaled by > define-key when you define a binding for C-a C-b when C-a is already bound > to a command). My feeling is that, if we have a decent infrastructure for developing and exchanging keymaps, people will do the work for themselves. (I recall that when X Windows first started, people found it to be a nightmare to customize them. But, very quickly, people started writing .Xdefaults files and exchanging them and the knowhow spread around. We can ask ourselves why people find it so much harder to do keymaps as compared to Xdefaults.) I guess we will discover what precedence rules are needed as we play with these features. For instance, it would have been much nicer if remap had precedence over the hard-coded bindings whereas it is the other way around at present. I think it would be best if the user can say which way the precedence should go. I will continue playing with the features you mentioned and see how well they work. Cheers, Uday