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: Wed, 28 Jul 2010 19:32:37 +0100 Message-ID: <19536.30661.376000.211406@gargle.gargle.HOWL> References: <19534.1494.627000.357123@gargle.gargle.HOWL> <87sk35upn2.fsf@uwakimon.sk.tsukuba.ac.jp> <87mxtcvpux.fsf@uwakimon.sk.tsukuba.ac.jp> <19535.7391.127000.704995@gargle.gargle.HOWL> <87iq40up12.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1280341990 25064 80.91.229.12 (28 Jul 2010 18:33:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 28 Jul 2010 18:33:10 +0000 (UTC) Cc: Uday S Reddy , Teemu Likonen , Stefan Monnier , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 28 20:33:06 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 1OeBRB-0002sH-SM for ged-emacs-devel@m.gmane.org; Wed, 28 Jul 2010 20:33:06 +0200 Original-Received: from localhost ([127.0.0.1]:34779 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OeBRB-00011X-8b for ged-emacs-devel@m.gmane.org; Wed, 28 Jul 2010 14:33:05 -0400 Original-Received: from [140.186.70.92] (port=55125 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OeBR4-00011I-DB for emacs-devel@gnu.org; Wed, 28 Jul 2010 14:32:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OeBR2-0001xi-Pv for emacs-devel@gnu.org; Wed, 28 Jul 2010 14:32:58 -0400 Original-Received: from sun60.bham.ac.uk ([147.188.128.137]:41135) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OeBR2-0001x8-In for emacs-devel@gnu.org; Wed, 28 Jul 2010 14:32:56 -0400 Original-Received: from [147.188.128.127] (helo=bham.ac.uk) by sun60.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1OeBQw-0003PN-P5; Wed, 28 Jul 2010 19:32:50 +0100 Original-Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1OeBQw-0004zk-FC; Wed, 28 Jul 2010 19:32:50 +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 1OeBQx-0002mO-DS; Wed, 28 Jul 2010 19:32:51 +0100 In-Reply-To: <87iq40up12.fsf@uwakimon.sk.tsukuba.ac.jp> 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:127938 Archived-At: Stephen J. Turnbull writes: > IME, users just don't do this, or want to do it; I really don't > understand what you're talking about. Please be more specific about > the use cases. I refer you to Teemu Likonen's post on the July 17, especially his comment that "there's not enough abstraction on that front [the key bindings of modes". In fact, a good part of the discussion in the "Emacs learning curve" was about the difficulty of changing key bindings, why the CUA mode can't be made the default etc. At least one use case that seems to be implemented in Gnu Emacs is to bind [remap undo] in modes that need it. So, if a user binds C-z to undo, he/she gets the appropriate undo in all modes (as long as they use remap for the key). I don't know if remap helps for rebinding C-c and C-x. That seems like too hard a problem for remap. The current practice is not necessarily indicative of what the users want to do. Many of us expected the key bindings of Emacs to be customizable, tried it, found it to be too hard and gave up. Some people persist because it is really important to them. It is their exasperation that keeps this debate alive. > In any case, your claim is mostly false for the keys where any of the > redesign vaporware could apply. In most modes, the mode keymap is > sparse; most of the shared bindings like self-insert-command, movement > commands, file opening commands, and buffer-switching commands are > *inherited* from the global map. They don't need to be changed. It might have been Barbara Liskov that said that the inheritance of implementation is not all that interesting, but the inheritance of interface is the interesting one. A have heard the comment from a lot of other people too. So, let us take inheritance of implementation for granted. There is nothing in particular to be said about it. remap allows you to inherit the interface (key-binding) and plug in a new implementation. > Most of the remaining bindings are very specialized; it's likely > that any replacements will also be idiosyncratic. IOW, remap only > helps if the user (or a minor mode) is already moving the command > around in the map. Sure, occasionally it's useful or perhaps > necessary. But how can that be a good idea on a regular basis? It is most helpful for people who want to move commands around the map, and they might want to do it on a regular basis. But I am proposing that "actions" should also be usable with the M-x prefix (or some similar prefix, since people will complain if the semantics of M-x is changed). So, one should also be able to do `M-x undo' in a dired buffer and get `dired-undo', and get `vm-undo' in a VM buffer and so on. This doesn't seem too hard to implement, but it requires us to separate the idea of actions/interfaces from keymaps. [Why allow this? Some people, me included, prefer to use memorable function names instead of remembering zillion key bindings. At the moment, the long names are made longer by the mode name prefixes like "dired-", "vm-" etc. It would be preferable to have simpler, general action names. If one uses speech recognition, key bindings are basically useless and actually get in the way. One would unbind all plain keys, and utter function names instead. Having to utter "dired blah" for every dired command is extremely cumbersome. So, we end up creating an additional layer of indirection at the speech level, translating "blah" into "dired blah". I don't yet see how the "action" idea can help with that. But I am hopeful.] Thirdly, I am proposing that interface inheritance need not only be from the global-keymap, but it could also be from generic local-keymaps. So, there could be, for instance, a generic-quick-actions keymap, which normally binds `n' to a `quick-next-line' action, `x' to a `quick-expunge' action etc. Both dired and VM could use this keymap, so that the user gets uniformity of key bindings. Moreove, the user can rebind keys in this generic keymap, e.g., move `quick-expunge' to `#' and leave `x' unbound. That would take effect in all modes that implement the generic-quick-actions keymap. That is a big win. You asked what "quick" actions are. They are the things that one would normally bind to plain keys. For example, `n' would be bound to `quick-next-line' whereas `C-n' is bound to `next-line'. How `quick-next-line' is performed is for the modes to determine. Dired might just do `next-line' in response, but VM Summary mode might display the next email message. > Sure, but we already have a concept of `action' (ie, a symbol denoting > a function): most Emacs commands follow this pattern. Most "generic" > bindings are simple enough to just inherit from the global map > *already*. Complex generic bindings like "fill-paragraph" and > "revert-buffer" provide hooks *already* so that modes can augment or > even entirely replace default implementations. Actions are *not* symbols denoting functions. They are symbols that sit on their own. They are bits of interfaces. It is possible, as you note, to make interfaces just be ordinary functions with dummy implementations. Smalltalk did that, but I think they found that the take-up was sporadic. Most developers just did implementation-inheritance and didn't bother with interface inheritance. On the other hand, when Java added interfaces as a first class concept, it had better success with the take-up. > Uh, what's a "quick action"? (I have no clue what you mean by that, > except "like vm-summary-next", which leaves a host of possibilities.) > Do you have a list of them? Does your list agree with those of the > maintainers of Gnus, Dired, buff-menu, and a host of other > maintainers? Do you all agree that you want these actions on the same > keys? I am not too fussed about the "quick" keyword. It was just the first thing that came to mind. Perhaps "modal" to mean that it depends on the mode. I am hoping that we all don't have to agree on the keys. The whole idea is to empower the user to allow for his/her favorite key bindings. But the actions, we would have to agree on, as far as the common actions go. That seems nontrivial, but not insurmountable. > If you can get definition, list, and agreement with *some* modes for > *some* "actions", you can get started. If you do actually make any > progress, let me know; I'll port/implement [remap] in XEmacs (and > SXEmacs if they don't have it yet). Ok, we have a deal! Cheers, Uday