Dave's difficulties with manual activities
in [Lisp]
|
Prev: Symbol reader macros
Next: Read CSV in SBCL
From: Alan Mackenzie on 7 Sep 2009 13:56 Hi, Dave, I think it's clear by now that Emacs isn't your sort of program, and you should stop telling everybody what you find difficult about it. We believe you, honest! Please also understand that a lot of Emacs's features that you slag off are precisely what Emacs users find useful, so the most accurate conclusion is that different people want different things from editors. Let us agree that it is good to have a choice in editors. By your complaints, it sounds like you'd prefer vi to Emacs. However, some parts of your rant are plain wrong, and I'd like to correct one particular wrong bit, so as third parties aren't mislead. In comp.lang.lisp Dave Searles <searles(a)hoombah.nurt.bt.uk> wrote: > With MS Word, the basic editing keystrokes like cut, copy, paste, and so > forth are known without consulting the MS Word manual, and furthermore, > the MS Word manual is a hypertext with clickable hyperlinks and an > easy-to-find-and-use table of contents, index, and search feature. Those commands need to be learnt from a manual (or another person) the first time they're used, whether you mean the one in MS Word or the ones in Emacs. > With emacs, the basic editing keystrokes like cut, copy, paste, and so > forth are NOT known without consulting the emacs manual, and the emacs > manual is just a buffer that comes up full of a very long piece of text > with no hyperlinked index or contents and no (obvious that I could find) > search capability. You're wrong here. The Emacs manual is a buffer, yes, but it's divided up into chapters, sections, pages, call them what you will. Only one page at a time (typically 30 - 150 lines long) is displayed at a time. The manual is extensively hyperlinked, indeed the Info program in Emacs was one of the earliest hyperlinkers, being written well before the WWWeb existed. Info was the first program to use <tab> to move to the next hyperlink. The first page of the Emacs manuas is a table of contents. You can often find what you're looking for here just by searching. I know you don't like it that you can use the exact same search commands here as in any other buffer, but you can. It's really quite handy. In fact, if you type C-s clipboard, that searches for and finds "clipboard". Hit CR twice, and you're on the page documenting "clipboard". [Note: "C-s" is "control-s", the search command.] There are several different index pages, which you can scan, or you can just type the "i" key followed by the word you're interested in. > Making matters worse, even were one to stumble upon the search feature > (assuming it has one, as seems likely) the manual is written in > emacsese rather than English. It's written in English, stylish, well written, and well organised. > It's chock full of "buffer", "kill", "yank", and so forth. A user who has difficulty grasping these simple, yet precise, terms is probably best advised to devote his modest intellectual talents to some lesser program. > A user searching for "copy" will find little of interest, If you type "i copy" you go directly to a page entitled "Using the clipboard". > and a user searching for "clipboard" may well be told "no matches > found". Er, no, as it happens. > The refusal to use what has become standard text-editing and > user-interface terminology in the emacs manual will cripple the > usefulness of any search feature and make any index or TOC > entries that ever did appear one day much harder to interpret; a > hypothetical TOC entry for "The Kill Ring" has no obvious relevance to a > user looking in the manual for the key bindings for basic clipboard > operations, yet I think that is precisely where that documentation would > be found. Have you tried it? The page "Kill Ring" (which indeed has a TOC entry) does indeed document some key bindings used for basic "clipboard" operations. However, as the Emacs manual has a hierarchical tree structure, you can just go up a node (command "u") and look at the menu (a mini TOC) in the parent node. You can nagivate easily from there. By the way, how come you're familiar with the Emacs jargon "ring"? ;-) > So the only apparent way to use the manual is to read the whole shebang > from front to back, and retain it all, relying on the ability of the > human mind to internally hyperlink knowledge it has acquired. Utterly wrong. See above. > In other words, the user has to do a bunch of hyperlinking sort of work > that, with MS Word, the computer does for them. Even more utterly wrong. Emacs had hyperlinking when MS was still making its money from MS Basic on Z80 home computers. [ .... ] > The evidence says otherwise; see above. Hmm. Evidence. Can be interesting stuff, you know. -- Alan Mackenzie (Nuremberg, Germany).
From: David Kastrup on 7 Sep 2009 14:24 Alan Mackenzie <acm(a)muc.de> writes: > In comp.lang.lisp Dave Searles <searles(a)hoombah.nurt.bt.uk> wrote: > >> With emacs, the basic editing keystrokes like cut, copy, paste, and >> so forth are NOT known without consulting the emacs manual, and the >> emacs manual is just a buffer that comes up full of a very long piece >> of text with no hyperlinked index or contents and no (obvious that I >> could find) search capability. The Edit/Search menu works here as well. >> Making matters worse, even were one to stumble upon the search >> feature (assuming it has one, as seems likely) the manual is written >> in emacsese rather than English. > > It's written in English, stylish, well written, and well organised. Yup. >> It's chock full of "buffer", "kill", "yank", and so forth. > > A user who has difficulty grasping these simple, yet precise, terms is > probably best advised to devote his modest intellectual talents to > some lesser program. Actually, I'd advise his intellectual talents to the menu entry Help / Documentation / Emacs Terminology if he already is familiar with computer jargon. If he isn't, he might as well work with the Emacs tutorial and/or the manual. All of which are available from the Help menu. -- David Kastrup
From: Dave Searles on 7 Sep 2009 22:02 Alan Mackenzie wrote: > Hi, Dave, > > I think it's clear by now that Emacs isn't your sort of program, and you > should stop telling everybody what you find difficult about it. We > believe you, honest! Then why do you continue to argue against what I say? If you are arguing against a position that you believe, then your behavior is most illogical. > Please also understand that a lot of Emacs's features that you slag off > are precisely what Emacs users find useful What "features that I slag off"? The only things I've "slagged" are *missing* features and standards non-conformance. The only "feature" of emacs that I object to IS standards non-conformance; any REAL feature of emacs can be left alone in most cases, and at worst needs to be moved to a different key combination, to achieve standards conformance. > Let us agree that it is good to have a choice in editors. By your > complaints, it sounds like you'd prefer vi to Emacs. Why on earth would I want THAT bucket o' bolts? > However, [personal attacks deleted, including accusing me of misleading > people] I will take that as your conceding that you don't have a logical argument against what I've said. Thank you. >> With MS Word, the basic editing keystrokes like cut, copy, paste, and so >> forth are known without consulting the MS Word manual, and furthermore, >> the MS Word manual is a hypertext with clickable hyperlinks and an >> easy-to-find-and-use table of contents, index, and search feature. > > Those commands need to be learnt from a manual (or another person) the > first time they're used, whether you mean the one in MS Word or the ones > in Emacs. That is entirely missing the point: the basic text-editing commands are Windows-wide and translate fairly readily to the Mac as well (command replaces control as the meta-key for some of them and that's about it). A user only needs to learn them ONCE, and typically does in school, and then they can use them in EVERY APPLICATION. Well, every application except emacs and other similarly-ill-behaved non-native ports, that is. On the other hand, emacs's idiosyncratic versions of these commands must be learned just for emacs's own sake. That knowledge is NOT learned early in life, is NOT useful beyond a single application, and is NOT otherwise useful. Worse, a user of emacs will have to remember to interact with emacs differently than how they interact with *every other application*. Because emacs is the only one that refuses to conform. Worse still, it apparently goes beyond binding the "wrong" keys to various functions, to oddball semantics and non-standard behaviors of a subtler sort, involving mouse and selection and focus handling. When one application does everything differently from all the others, while all those others are fairly consistent among one another, the one application can quite fairly be charged with "not getting along well with others" I think. By this time, the Windows interface is a very well established standard, so any application still actively maintained that continues to severely deviate from typical computer users' expectations must be doing so deliberately; it is not so much broken as a maverick intentionally defying the user and purposely not going along with the crowd. As a result it will not see much adoption. It will be criticized for doing things in oddball ways and refusing to adapt to the modern era. Flaming me won't make any difference to those facts. It won't magically make what I've said stop being true and miraculously trigger a renaissance of emacs-use with a sudden massive spike in adoption. It can't do this anymore than the RIAA's various lawsuits and lobbying will put the digital genie back in the bottle or newspapers all colluding to create a paywall will result in everyone paying for news again. You can't turn back the clock. The world has moved on, and the vast majority of the people have spoken. The emacs style of interface is yesterday's news. Get over it, already. >> With emacs, the basic editing keystrokes like cut, copy, paste, and so >> forth are NOT known without consulting the emacs manual, and the emacs >> manual is just a buffer that comes up full of a very long piece of text >> with no hyperlinked index or contents and no (obvious that I could find) >> search capability. > > You're wrong here. No, I am not. > The Emacs manual is a buffer, yes, but it's divided up into chapters, > sections, pages, call them what you will. It's a text file. I didn't claim it was entirely un-organized; it is organized something like a paper book. And that is the problem. Such an organization is unsuited to digital viewing, browsing, and manipulation. You can't just click some cross-reference to follow it; and even in a paper book, if it said "see xyz on page 134" you could flip to page 134 and you'd have a single page to search for what you were interested in. Here we have the worst of both worlds: no hypertext links and no page numbers to flip to either. There's a reason why the entire rest of the software industry has migrated to hyperlinked, searchable help with tables of contents that contain hyperlinks and with hyperlinked indices. It baffles me why so much of emacs remains stuck in the past, refusing to move beyond what was the state of the art circa 1985. Especially when in a few superficial ways it HAS moved beyond that, yet in many crucially important ways it simply will not budge. [snip much that appears to be nonsense] If I had never used emacs you might have been able to fool me. But I have used it and I have struggled with its online help. It does not have hyperlinks, nor a proper table of contents. As stated above, it is organized like a printed manual (and even has instructions near the start on how to print it), but lacks even a printed book's primitive method of cross-referencing: page numbers. >> Making matters worse, even were one to stumble upon the search feature >> (assuming it has one, as seems likely) the manual is written in >> emacsese rather than English. > > It's written in English, stylish, well written, and well organised. It's written in English heavily laced with an emacs-specific technical jargon, rather than in plain English. As for how it's organized, it is that this organization is not accessible to automation that bothers me. Simply having a text file that reads like a printed book is nowhere near the present-day state of the art in online help systems and you know it. >> It's chock full of "buffer", "kill", "yank", and so forth. > > A user who has difficulty grasping these simple, yet precise, terms Who said anything about difficulty? My complaint is with inconsistency: 1. These terms are not intuitive; why should a technical jargon have to be mastered to use a *text editor*?? We're not talking about a nuclear reactor or 3DSMAX here, we're talking about a glorified Notepad. And nobody has to learn any technical jargon to write a letter to Grandma in Notepad. 2. These terms are inconsistent with the industry-standard ones used everywhere else. So users will have to learn TWO sets of terms to use emacs and other applications, versus one to use any combination not including emacs. 3. Because of item number 2, searching (or just visually skimming) the help file for the term the user is likely to think of for something is likely to draw a blank because the emacs manual refers to it using its own idiosyncratic terminology instead of the terminology computer users are used to. Perhaps you should read Jacob Nielsen's Alertbox columns. He focuses on web interfaces but some of the guidelines he comes up with are more broadly applicable. One of those is: If your site (application) is different from all the others that do the same job in ways that make it require extra effort or special training to use, users will go elsewhere. Another one is: Using clever neologisms and idiosyncratic terminology will backfire. With web sites this is because people Googling using the normal words for your products or services won't find your site because it doesn't use the normal words. But it is equally applicable to application help text: it degrades searchability of that text, of ANY text, if you don't use the same words to describe things that EVERYONE ELSE IN THE SAME INDUSTRY uses. These are important usability considerations and you have repeatedly failed to consider them or to provide anything approaching a reasoned rebuttal to these arguments. I will take that as your conceding that you don't have a logical argument against what I've said. >> A user searching for "copy" will find little of interest, > > If you type "i copy" you go directly to a page entitled "Using the > clipboard". This statement of yours has multiple problems: 1. As I've already explained, the emacs help text uses "kill" and "yank" and "kill ring" in place of "cut" and "paste" and "clipboard"; everyone here surely knows this. Furthermore I can't recall it saying anything about "copy". 2. I've never heard of this "i copy" thing, and even if that actually somehow works it will land you on a page that discusses the "kill ring", and furthermore there's no way for a naive user to even discover that command anyway (what, it's in the help and "i help" will tell them all about it? Er, just *think* about that for a minute...) 3. And if "i copy" DOES work, then there's an even more serious problem which is that you can't easily edit text containing the letter "i". Presumably there's some way to escape and type a literal "i" but who is ever going to guess that? No text editor should respond to the ordinary typable symbols (when the focus is on the main text-editing area of its user interface) in any way other than by inserting the typed symbol at the insertion point in that text file and moving the insertion point to the right one character (so it's now immediately after the freshly-inserted symbol). Violation of that rule is one of vi's principal faults, and now it transpires that it is also one of emacs's. How many users get tripped up when they go to write a letter to Grandma and start typing, only when they hit "i" the help suddenly opens and grabs focus and interprets the next several keystrokes as some sort of search query? >> and a user searching for "clipboard" may well be told "no matches >> found". > > [personal attack deleted] I will take that as your conceding that you don't have a logical argument against what I've said. >> The refusal to use what has become standard text-editing and >> user-interface terminology in the emacs manual will cripple the >> usefulness of any search feature and make any index or TOC >> entries that ever did appear one day much harder to interpret; a >> hypothetical TOC entry for "The Kill Ring" has no obvious relevance to a >> user looking in the manual for the key bindings for basic clipboard >> operations, yet I think that is precisely where that documentation would >> be found. > > Have you tried it? The page "Kill Ring" (which indeed has a TOC entry) I don't count it unless there's an easy way to jump from the "TOC entry" to the chapter or section at issue. In a Windows help file, displayed in the Windows help browser, there is. Emacs just displays the help as a text file, or even just a part of the help, and a read-only one at that; all you can do, therefore, is read it. A text editor makes a poor help browser. Why do you think Notepad's help opens up in a winhelp window rather than as a Notepad window containing a ginormous readme file? Because the latter would be difficult to navigate and use, though at least in Notepad you'd be able to count on control-F <term> enter to search for a term in that file. > does indeed document some key bindings used for basic "clipboard" > operations. While failing to call them by the industry-standard names. (And if it does retain a history of past clipboard entries, it can't possibly be doing so using the system-native clipboard on Windows or, I expect, the Mac. So there's another problem: if you cut text in emacs and then try to paste it in Thunderbird or whatever, you'll get nothing or the wrong text out of the paste. The headaches for the emacs user just multiply and multiply. It is increasingly clear that emacs was designed to be used in isolation, by someone completely unconcerned by the fact that in the real world people use a lot more applications than just one text editor on their computers. This is why it does not get along well with others; it is not just apparently designed for autistic *people*, it is autistic *itself*, and not high-functioning either; it is locked in its own world, oblivious to technological advancements, standardization processes, terminology, expectations, or other information from the entire rest of the world.) > By the way, how come you're familiar with the Emacs jargon "ring"? ;-) Because I have used emacs. Yes, you have in fact run across something you thought didn't exist (or, perhaps, did not want to admit existed): someone who HAS used emacs that nonetheless is critical of it. >> So the only apparent way to use the manual is to read the whole shebang >> from front to back, and retain it all, relying on the ability of the >> human mind to internally hyperlink knowledge it has acquired. > > [personal attack deleted] I will take that as your conceding that you don't have a logical argument against what I've said. >> In other words, the user has to do a bunch of hyperlinking sort of work >> that, with MS Word, the computer does for them. > > [personal attack deleted] I will take that as your conceding that you don't have a logical argument against what I've said. >> The evidence says otherwise; see above. > > Hmm. Evidence. Can be interesting stuff, you know. I will take that as your conceding that you don't have a logical argument against what I've said. Thank you.
From: Dave Searles on 7 Sep 2009 22:04 David Kastrup wrote: > Alan Mackenzie <acm(a)muc.de> writes: >> In comp.lang.lisp Dave Searles <searles(a)hoombah.nurt.bt.uk> wrote: >>> Making matters worse, even were one to stumble upon the search >>> feature (assuming it has one, as seems likely) the manual is written >>> in emacsese rather than English. >> It's written in English, stylish, well written, and well organised. > > Yup. I have written a detailed rebuttal of Alan's post as a direct followup to that post; suffice it to say here that a) it is laced with technical jargon which, moreover, is not the technical jargon the ENTIRE REST of the editor industry uses, and b) its organization is like a printed manual and is not amenable to computer-assisted browsing, unlike the help files of truly modern applications when viewed in truly modern help browsers.
From: Ravi on 7 Sep 2009 23:12
Dave Searles <searles(a)hoombah.nurt.bt.uk> writes: > Alan Mackenzie wrote: >> Hi, Dave, >> >> I think it's clear by now that Emacs isn't your sort of program, and you >> should stop telling everybody what you find difficult about it. We >> believe you, honest! > > Then why do you continue to argue against what I say? If you are arguing against a position that you believe, then your > behavior is most illogical. > >> Please also understand that a lot of Emacs's features that you slag off >> are precisely what Emacs users find useful > > What "features that I slag off"? The only things I've "slagged" are *missing* features and standards > non-conformance. The only "feature" of emacs that I object to IS standards non-conformance; any REAL feature of emacs > can be left alone in most cases, and at worst needs to be moved to a different key combination, to achieve standards > conformance. And I'm sure your bitching and whining serves some productive purpose to this. > The world has moved on, and the vast majority of the people have spoken. The emacs style of interface is yesterday's > news. Get over it, already. What are you trying to achieve here? Some sort of sea-change that will get everything well and good and the way you think it should be? |