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: Info tutorial is out of date Date: Sat, 15 Jul 2006 10:07:01 -0700 Message-ID: References: <858xmu9aft.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1152983355 18995 80.91.229.2 (15 Jul 2006 17:09:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 15 Jul 2006 17:09:15 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 15 19:09:12 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G1ndZ-00054n-6I for ged-emacs-devel@m.gmane.org; Sat, 15 Jul 2006 19:09:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G1ndY-00039y-HD for ged-emacs-devel@m.gmane.org; Sat, 15 Jul 2006 13:09:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G1ndM-00039m-IU for emacs-devel@gnu.org; Sat, 15 Jul 2006 13:08:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G1ndJ-00039a-3I for emacs-devel@gnu.org; Sat, 15 Jul 2006 13:08:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G1ndI-00039X-Sl for emacs-devel@gnu.org; Sat, 15 Jul 2006 13:08:48 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1G1nfY-00012Y-LI for emacs-devel@gnu.org; Sat, 15 Jul 2006 13:11:08 -0400 Original-Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k6FD4EWk011363 for ; Sat, 15 Jul 2006 12:08:47 -0500 Original-Received: from dhcp-amer-csvpn-gw2-141-144-72-156.vpn.oracle.com by rcsmt250.oracle.com with ESMTP id 1569728711152983228; Sat, 15 Jul 2006 11:07:08 -0600 Original-To: "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <858xmu9aft.fsf@lola.goethe.zz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Whitelist: TRUE 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:57054 Archived-At: > In general (exceptions can be made), key bindings should not be > introduced until much later, and then they should be introduced as > shortcuts for functionalities the user already knows by then. It is > the functionalities that should be on the agenda, not the keys. The > emphasis is all wrong in this respect. You lose the forest of > functionalities because of all the trees of keys. I disagree with most of your posting. I figured someone would ;-). The tutorial might have gotten where it is mostly out of neglect, but I figured there might also be some active forces involved. Someone wrote node `Help-Inv' (should be named `Invisible-Hell') fairly recently, for example. Anyway, there's room for disagreement; it's really I who's disagreeing with the status quo, after all. Mouse navigation remains an inefficient crutch compared to keys. Generally true. We're on the same team here - I have no stock in mice (or anything else, unfortunately). The point is to ease the learning of Info. The most important thing to learn is what Info is, what it has to offer, what you can do with it, why you should be interested in it - that is, its *features*, not how you can most efficiently use those features. *What* first, with an easy-learning-curve, super-simple, obvious *how*, to help introduce the *what*. More efficient *how* learning later, if at all. If you want, the tutorial could be split in two: first "What Info Is" (with simple how-to, to get the points across), second "How To Use Info Efficiently". My point is this: first things first. If I don't understand what Info is all about, why would I go through the effort of learning and practicing its key bindings? I have nothing against recommending that one learn to use keys for efficiency, but let's first get the main point across. It [mouse] is somewhat efficient for exact cursor positioning, but that still requires letting go of the keyboard. Using info efficiently entails using the keys. This is about learning - in particular learning what Info is, what it is for, how it is laid out/structured, how to find information with it. Of course, this is doubly important on ttys or for disabled people, Huh? Want to bet whether disability is better served by a single-point device or a keyboard full of keys and chording? Of course, it can depend on the disability. Think of all the jokes when the mouse first came out, about how it was designed for a one-armed person with one finger. Using a full keyboard, and chording especially, is hardly for everyone. But really, if we're already reaching to the "disabled" to bolster an argument here, then we're reaching for straws. The point is not about which interaction with Info is most efficient for which group of people on which equipment; it is about how to teach what Info is all about, how to give people an initial access to the manuals (which is what Info is for), how to get them comfortable with Info and have them see how it can be useful to them. People find their own preferred ways to interact with programs and equipment, and it's easy enough to find the keys that you and I both promote. I mentioned two ways those keys can be made more visible (more visible than trudging through the current tutorial): 1) have `h' show a short list of key bindings with one-line descriptions, 2) the menu-bar menu shows key bindings at a glance. Both of these give an *overall* view of the important key bindings, and they provide quick reminders. (`h' would mention SPC and DEL also, which the menu-bar menu doesn't show.) I also mentioned the need to have specific tutorial instruction for those keys (e.g. SPC and DEL) that are *not* so obvious. Teaching `n' right away is a waste of time, not because `n' is useless, but because there is an obvious (if perhaps somewhat slower) way to do the same thing. The point is to get quickly to the point, not to spend time teaching how to use the keyboard. As to the fingers-leaving-the-keyboard argument: That is not such a strong argument for Info, where people are reading, not editing. Yes, using the keyboard for SPC and DEL has no mouse equivalent (AFAIK); otherwise, you can get by about as fast with the mouse as with keys, in Info. But I won't try to win that argument, because it is not an important argument - what's important is the argument over what we're trying to teach. You know, touch typing is also much more efficient than (the "inefficient crutch" of) pecking with one finger (though I've seen cases to the contrary!). Should we start the Info tutorial with a lesson in touch typing, because it is more efficient? This is about *getting information*; it's not about teaching the fastest way to do that - that can come later. but in any case there is absolutely no sane rationale for futzing around with scroll bars when the space bar is fully accessible. And most scroll bars don't even allow you changing the direction of scrolling without having to move the mouse Excuse me? Did someone mention scroll bars in this context? What is that all about? On the contrary, didn't I say that SPC and DEL should be taught explicitly (and early) in the tutorial, because they are not obvious (visible)? What are you talking about wrt scroll bars? Here's my criticism, in a nutshell: 1) teach what Info is about, first; 2) start using the obvious how-to (e.g. links, buttons, menu-bar), to teach #1; 3) teach the non-obvious how-to (e.g. SPC, DEL) also; 4) don't bother teaching the obvious, if more-efficient, how-to (e.g. `n'), except possibly as an efficiency booster, after getting the real message across.