From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: florian@fsavigny.de (Florian v. Savigny) Newsgroups: gmane.emacs.help Subject: Re: Learning "my emacs" from the start Date: Sun, 20 Apr 2014 15:00:13 +0200 Message-ID: <87vbu4upeq.fsf@bertrandrussell.Speedport_W_723V_1_32_000> References: <3defe928-5d2e-4d3b-bc26-f595f275f840@googlegroups.com> <83lhv0fmrk.fsf@gnu.org> <87mwfg5lop.fsf@zigzag.favinet> NNTP-Posting-Host: plane.gmane.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1397999420 27854 80.91.229.3 (20 Apr 2014 13:10:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Apr 2014 13:10:20 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Apr 20 15:10:11 2014 Return-path: Envelope-to: geh-help-gnu-emacs@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 1WbrVb-0007K9-Jy for geh-help-gnu-emacs@m.gmane.org; Sun, 20 Apr 2014 15:10:11 +0200 Original-Received: from localhost ([::1]:45534 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbrVa-0007XE-T5 for geh-help-gnu-emacs@m.gmane.org; Sun, 20 Apr 2014 09:10:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbrVK-0007Wu-IR for help-gnu-emacs@gnu.org; Sun, 20 Apr 2014 09:10:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WbrM1-0003UU-C0 for help-gnu-emacs@gnu.org; Sun, 20 Apr 2014 09:01:22 -0400 Original-Received: from srv4.ns-domain-hosting.de ([178.63.89.203]:53575) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbrM1-0003Ri-0Z for help-gnu-emacs@gnu.org; Sun, 20 Apr 2014 09:00:17 -0400 X-No-Relay: not in my network Original-Received: from bertrandrussell.Speedport_W_723V_1_32_000 (p4FECD8F7.dip0.t-ipconnect.de [79.236.216.247]) by srv4.ns-domain-hosting.de (Postfix) with ESMTPSA id ACF3D186955 for ; Sun, 20 Apr 2014 15:00:15 +0200 (CEST) In-reply-to: <87mwfg5lop.fsf@zigzag.favinet> (message from Thien-Thi Nguyen on Sun, 20 Apr 2014 12:39:50 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 178.63.89.203 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:97257 Archived-At: > From: Thien-Thi Nguyen >=20 > I agree OP's way is impractical and inefficient, but that doesn't mea= n > it is impossible or undesirable. It's no problem for people to scope > out the joint before joining the party; the door is always open and t= he > Software is (as always, thank GNU very much) Free. Too, some sidewal= k > spectacle is its own reward, and keeps the puke out of the punchbowl.= .. Hmm. I am a bit unsure about what precisely you mean by "keeping the puke out of the punchbowl" - would you mind explaining that? Provided this expression does not completely change the meaning, I understand you mean that it is an interesting experiment, to which I would agree. It would seem to me that Hans' list of symbols function could turn out useful as an additional diagnostic tool for people who are trying to take a look behind the scenes for whatever reason, but at the same time finding it to cumbersome to read the whole source code of whatever package or functionality. Nevertheless, Hans, I have to admit I still do not really understand how you are going to understand Emacs better by looking at hundreds of symbols (or maybe I have got something wrong). From my experience, the Lisp symbols actually in use range from the highly important to the rather obscure (i.e. those which only have a role for working around some glitch, or which the programmer only introduced because (s)he had no better idea, or whatever). I am particularly puzzled because you are calling the learning curve for Emacs amazingly steep. That might be true, even if I am far from sure about that -- it would seem to me that the learning curve chiefly has to do with the keybindings, which are manageable, and probably the fact that there is always more to learn, but the latter is something you do not HAVE to do, and otherwise actually a nice fact - you often discover additional functionality as you start desiring it. (AKA "There should be a function that...," followed by the discovery that it actually already exists.) But most importantly, I cannot imagine how the learning curve with your method can be any less steep, instead of, I imagine, about 10 times steeper. As to the keybindings, I think you do have a point here, but the issue is actually complicated. The double (not to mention even longer) combinations a la C-x C-f can indeed be cumbersome if you need them often. If, that is. C-x C-f is not a good example, because it is used rarely enough not to make itself noticeable as cumbersome. And some commands are so rarely used that it actually makes more sense to call them with M-x and by their names. Nevertheless, even if Microsoft bindings such as C-v for paste and C-c for copy can be called a standard with good reason, given the prevalence of Windows systems, I think you need to take into account that those which "everybody" knows only call a small handful of functions (I, for one, can think of C-c, C-x, C-v, C-o, C-p, C-a, C-s, C-z, and C-y), and it is obvious that this scheme cannot accomodate more than 26 commands. (Alt- always calls a menu.) Thus, those bindings are not that powerful if looked at closely, while the Emacs bindings are almost infinitely extensible. I virtually never call a menu when I work in Emacs. (When I do, I literally use them as "menus", i.e. to have a look at what else is on offer.) Second, from my experience, many grandmothers work at Windows PCs without even using (or knowing) C-c and the like. Third, the Emacs style of keybindings is also a standard (as, as I suppose, the vi-style bindings are, but I have no experience with vi). It is used, for example, on the bash command line, and in many Unix programs. Fourth, some, perhaps many, Emacs keybindings are more ergonomic: C-e and C-a are easier to reach than End or Home, and M-f and M-b more so than C-left arrow and C-right arrow. (And, arguably, reserving Alt-Letter for menus can be called a design error in that respect.) Marking a region is also more ergonomic... What I do agree with is that the unfamiliarity of Emacs bindings can turn people away from Emacs before they notice it is not actually a big deal. (My impression is actually that it is important how memnonic the key combinations are - M-f and M-b, for example, are easy to remember, while C-w is unintuitive. It is natural to me now, but only because I have used it for years.) What is also a bit of a problem is the concurrence of the two standards - I regularly have to work in LibreOffice Writer, and sometimes inadvertently use Emacs keys there. Thus, it might be a really worthy undertaking to explore if it is possible to find a scheme that reasonably reconciles these two standards, i.e. finds the best subset, both in terms of memnonics and ergonomics (but then I don't know anything about Mac bindings - still different?). A bit like a Unicode for keyboard commands, that is. Independently, the most useful approach is probably an individual one. As others have pointed out, impractical keybindings do exist (C-c C-o C-a, for example, for nxml-show-all, is really an absurd monster.) But then it would be best to observe which functions you call how often, and define really short keybindings for them. As others have pointed out, you can always find such free short keybindings. And even if you really don't, you can still redefine keys. (My personal favourite for more rare commands is the style C-c a [abc] for a related family of commands, i.e. using a single letter (here, "a") as another prefix key. In this example, you'd get C-c a a, C-c a b, or C-c a c, i.e. three commands which start with C-c a.) By the way, is there a function analogous to open-dribble-file, which records all the COMMAND calls (not keys), and which would enable you to statistically evaluate how often you call which function? That would certainly be of great help to anybody wishing to define more keyboard commands that enable them to write more ergonomically. [Sorry if this has got rather long. I have shortened, but now I am running out of time.] --=20 Florian von Savigny Melanchthonstr. 41 33615 Bielefeld