From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.pretest.bugs,gmane.emacs.devel Subject: RE: Tutorial incorrectly thinks emacs -Q uses customizations. Alarmist and confusing tutorial intro. Date: Sat, 27 Jan 2007 18:26:39 -0800 Message-ID: References: <45BBFE5A.20501@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1169951267 7704 80.91.229.12 (28 Jan 2007 02:27:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 28 Jan 2007 02:27:47 +0000 (UTC) Cc: Emacs-Pretest-Bug , Emacs-Devel To: "Lennart Borgman \(gmail\)" Original-X-From: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Sun Jan 28 03:27:41 2007 Return-path: Envelope-to: gebp-emacs-pretest-bug@gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HAzla-0005QA-QD for gebp-emacs-pretest-bug@gmane.org; Sun, 28 Jan 2007 03:27:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HAzla-00027D-8j for gebp-emacs-pretest-bug@gmane.org; Sat, 27 Jan 2007 21:27:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HAzlP-00024J-Ei for emacs-pretest-bug@gnu.org; Sat, 27 Jan 2007 21:27:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HAzlN-000215-Qw for emacs-pretest-bug@gnu.org; Sat, 27 Jan 2007 21:27:26 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HAzlN-00020w-O9; Sat, 27 Jan 2007 21:27:25 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1HAzlN-0008OD-8B; Sat, 27 Jan 2007 21:27:25 -0500 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l0S2RL8v019222; Sat, 27 Jan 2007 19:27:21 -0700 Original-Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l0S2HEUa005075; Sat, 27 Jan 2007 19:27:21 -0700 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-81-26.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 2402002531169951201; Sat, 27 Jan 2007 19:26:41 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <45BBFE5A.20501@gmail.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-pretest-bug@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for CVS Emacs." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Errors-To: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.pretest.bugs:16837 gmane.emacs.devel:65550 Archived-At: > Could you please propose a better text? As I said, I prefer that we not use this. I think it has a negative effect. > I am not quite sure "had" is incorrect here. The state of the TUTORIAL > buffer may have changed since the link was created. Is not "had" the > correct word then? Or how would you say it? I wouldn't say it. I would just say something generic, without trying to determine whether the user had actually customized Emacs. Something short and simple, such as this: "Keys mentioned in this tutorial are those defined by default. If Emacs has been customized, then some keys might differ from those mentioned here. If you want to use the tutorial with the standard Emacs keys, then start Emacs again using `emacs -Q'." IOW, "YMMV". This need not be in red, and it need not be the very first thing the user reads. It should not be. Put it after the first place where the tutorial asks you to use a key, as a footnote. "YMMV" belongs in the fine print (more or less). > These text should only be showed if some of the key bindings used in the > tutorial have been changed. In other words they are only showed when the > tutorial does not work. I don't agree that that is worthwhile. Just let users know that the tutorial is written for standard (i.e. default) Emacs bindings. That's all. The tutorial should not (IMO) be mostly about teaching keys, anyway. If it is, then that's a mistake. Keys are only a means to Emacs functionalities; we shouldn't concentrate too much on them. Users can learn Emacs using emacs -Q, and they can then learn different bindings afterward, if need be, for their customized version. > We discussed what to do in this case earlier. We decided then that the > best way to handle it was to tell the user about the problem. Other > alternatives was to refuse to run the tutorial or to change the key > bindings in the tutorial buffer so that they matched the tutorial. I think the cure is worse than the disease. There is no reason to refuse to run the tutorial or to try to adapt it. Just let users know that it assumes standard (default) bindings. Keep it simple. Users should get the same behavior each time they use the tutorial, whether with customized or vanilla Emacs - any other behavior is confusing. Referential transparency and all... > Some more work can be done on this. It fails with very long names if I > remember correctly now. But I felt this was good enough. It's not needed. I don't think users who have customized versions of Emacs really need to be told just which bindings have changed. It's true that some of the tutorial won't "work" or even make sense to them without knowing which keys to use, but it should be clear that they can always use the tutorial with emacs -Q. We don't need to make the tutorial work for customized bindings. > I am not sure what is best. Of your proposals I like the first one best. > What do others think? None of them are needed. I shouldn't even have mentioned them. My point was that what is there now is harmful, because confusing (and scary). > > Another bug, unrelated to the tutorial: Clicking > > `delete-backward-char' does > > not show its binding (DEL). The doc string needs to mention this. > > This is disturbing but maybe a bit hard to fix right now. I would rather > put that in TO-DO for after the release. `delete-backward-char' is a built-in function. It should be possible to fix this detail. (Again, it has nothing to do with the tutorial.) > > Most importantly: Do we really need this? > > Yes, I believe we need it. The idea is simply to tell the user let the > user run the tutorial even though some things have changed, but inform > the user what has changed. I think without this the user may get very > confused when the tutorial does not work. The confusion is 100x now. I see no need for the user to run the tutorial using customized bindings. If you could automatically adapt the entire tutorial to reflect the user's bindings perfectly, then I guess it could be OK (but see above, about same, repeated behavior). However, that is too difficult, and any half measure is worse than none at all. > Whether this is the best way to handle the problem with changed key > bindings that affects the tutorial is another question (see above). That's the question. My answer is "No". > > This is crazy. This is the FIRST thing that a newbie will see, when > > trying to learn about Emacs. > > If no key bindings have been changed the user will not see this. (When > the bug has been fixed.) That bug really needs to be fixed, at a minimum. Right now, we're scaring 100% of the people who try the tutorial 100% of the time. Messing their minds, to no good end. > > Please, let's drop this or redo it completely. If we keep it, it > > needs to be 1) simple, 2) unalarming, 3) obviously of secondary > > importance. A tutorial should hold you by the hand in the beginning, > > not scare and confuse you. > > IMO this is the wrong level to discuss it on. We should rather discuss > the GUI instead and how that can be used to teach the user Emacs. After > the release of course. Fine, let's discuss the GUI and the tutorial and lots more after the release. But let's please pull this enhancement now; it's not ready for prime time. The last thing we want the tutorial to do is confuse and scare new users. Emacs already has a reputation for being difficult to learn and use. And supposed key-binding madness is a big part of that bad rep. The tutorial should make you feel self-confident, showing you that *YOU CAN* use Emacs without being a key-binding wizard. If bindings are getting in the way, then the tutorial has not done its job. I feel so strongly that it is not mainly about learning keys, that I wouldn't mind if the tutorial started with just the menu (which requires no explanation to start using), but we've been down that path before...