From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Unuseful keybindings Date: Sun, 23 Dec 2012 10:51:59 -0800 Message-ID: <744C1BFE989545DF9F82E4DE55002679@us.oracle.com> References: <87sj73qzvl.fsf@gmail.com> <87623zquvw.fsf@gmail.com><87ip7zdud3.fsf@gmail.com> <87ehiiu5x7.fsf@gnu.org><876A7D1112084247AE53F7EE42B4587C@us.oracle.com><80ehih3hlj.fsf@somewhere.org> <87pq21iwrw.fsf@yandex.ru> <87AE81CEB91846DB94BC5F3B40C788DE@us.oracle.com> <50D64318.5030501@yandex.ru> <0FBA2D9ECA214D82B5C65E5A09E7EE19@us.oracle.com> <50D71824.90601@yandex.ru> <1C9978ED468E4CC8948C1B93D6806A18@us.oracle.com> <50D7405E.5070604@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1356288748 7332 80.91.229.3 (23 Dec 2012 18:52:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Dec 2012 18:52:28 +0000 (UTC) Cc: 'Sebastien Vauban' , emacs-devel@gnu.org To: "'Dmitry Gutov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 23 19:52:43 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TmqfA-00051g-Kv for ged-emacs-devel@m.gmane.org; Sun, 23 Dec 2012 19:52:40 +0100 Original-Received: from localhost ([::1]:37135 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tmqew-0004wh-Nk for ged-emacs-devel@m.gmane.org; Sun, 23 Dec 2012 13:52:26 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tmqer-0004vC-4i for emacs-devel@gnu.org; Sun, 23 Dec 2012 13:52:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tmqek-00029J-Tj for emacs-devel@gnu.org; Sun, 23 Dec 2012 13:52:21 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:16621) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tmqek-00029C-MM for emacs-devel@gnu.org; Sun, 23 Dec 2012 13:52:14 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBNIqB1r020437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 23 Dec 2012 18:52:13 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qBNIqAv1015849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Dec 2012 18:52:11 GMT Original-Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qBNIqAIX016127; Sun, 23 Dec 2012 12:52:10 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 23 Dec 2012 10:52:10 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50D7405E.5070604@yandex.ru> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac3hM5yRMjBaGpugSyO0rSUbQ38ufQABNaeA X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:155826 Archived-At: > > And your consistency argument works both ways: Why not > > consistently remove all function-key default bindings? > > This is reductio ad absurdum. Not every kind of consistency > is equally valuable. Precisely my point. IF you use that kind of argument THEN it applies equally in the other direction. It's not about consistency vs inconsistency in the abstract. > >> The possible reason why those keys are so nice and still > >> mostly have no bindings is they are far from the home row, > > > > I believe that Emacs Dev intentionally avoided binding them > > by default. They were left for users and applications. > > > > `home' (Home) and the arrow keys are far from the home row also. > > They have been bound since they existed, AFAIK. > > Because they behave the same way in many other programs, I'd wager. > f-keys, on the other hand, have not enjoyed the same degree of > consistent behavior across programs. That function keys are not so standard is one reason not to bind them by default. But it is certainly not the only reason, or even the most important reason. > >> not in a sequence in the middle of other commands during > >> an editing session. > > > > Why? Wanna guess how many users hold down an arrow key to > > repeat its command? > > > > Imagine if Emacs Dev had misguidedly bound `down' (the down > > arrow) by default to a non-repeatable command such as > > `fullscreen'. Not as useful as the key could be. > > Is that the only reason you think binding `down' to `fullscreen' is > ill-advisable? :) The point is that `down' is bound to a repeatable action. For that reason alone the binding would be reasonable even if it did not also agree with outside convention. On the other hand, `home' is not repeatable. About the only argument in favor of binding `home' as we do (that I can think of) is the argument of consistency with other apps. >From my own point of view, if we ever came to the point where we had an important repeatable command and we had no available repeatable keys on which to bind it by default, I would probably sooner sacrifice our externally consistent `home' binding than lose the convenience (yes, by default) of that command's repeatability. Binding `home' to a non-repeatable, non-prefix command is, _in itself_, a waste. It is OK to do, in order to be consistent with other apps, as long as the scarcity of repeatable and prefix keys has not reached a critical level. If it got critical then `home' would be up there in the top 10 for regrooving, in my book. Why don't I apply the same reasoning to `f11'? I do, but the context is different: (a) function keys have in the past been reserved for users and apps; (b) this is now and that was then, and back then there were more repeatable keys still virgin (more coral reefs unspoiled); (c) I'm not convinced that `f11' for fullscreen is so commonly used as `home' is, outside Emacs. I do not expect everyone to share this more extreme point of view that even longstanding `home' could conceivably be sacrificed for a better command. That is not necessary for my general point. But yes, I do think that what's good for Emacs and Emacs users comes first, not consistency with external apps. The question in that context would be, for me at least, which is better for Emacs users: provide a default binding to a repeatable key for the important Emacs command or keep `home' compatible with the outside world. And yes, I recognize that Emacs users do not use only Emacs. That's one thing that makes such questions interesting, not black & white. > >>> There is absolutely no reason for Emacs to bind `f3' and > >>> `f4' by default. > >> > >> These keys are featured on the Emacs tour page, so there's > >> no getting rid of them now, I suppose. > > > > That's silly. Just update the tour to use `C-x e e e e > ...' or whatever. > > Emacs has a policy of backwards compatibility, whenever possible, or > something. Whenever possible? No. Backwards compatibility, like mirroring external conventions, is a relative good, not an absolute criterion. Emacs Dev has not been so black & white. We are not dogmatists. > Think back to the latest reversal of the `M-=' binding, which has > received a rather small backlash. I didn't follow it closely, but I think that thread rather supports what I'm saying. Nothing is cast in concrete. Changes were made wrt `M-=', and comments from others were taken into consideration.