From: utzoo!decvax!harpo!npoiv!npois!ucbvax!C70:editor-people Newsgroups: fa.editor-p Title: Re: editors having too many commands Article-I.D.: ucb.1756 Posted: Thu Aug 12 03:10:13 1982 Received: Sat Aug 14 04:44:30 1982 >From JWalker@SCRC-TENEX@MIT-MC Thu Aug 12 03:07:25 1982 From: Maurice J. WutsTo: Editor-People at SU-SCORE Subject: Re: editors having too many commands There can be such a thing as an editor with too many commands. Personally I like as many and as powerful commands as possible, but we have some users that only do light editing and are not likely to get familiar with something as large as EMACS. We have tried to teach our secretaries EMACS, but they tend to get overwhelmed by the number of commands and the power of them. Commands that can destroy an entire day's work with a single keystroke are just too powerful in the hands of someone that is unable or unwilling to really learn the editor. On the other hand the beauty of EMACS is that it was possible to write a library with enough commands to get the job done, but none so powerful as to be dangerous. We also put most of the commands on Heathkit or VT100 keypads and eliminated all the meta-cokebottle flavor commands. I'd hate to have to use this library, but at least our systems programmers and novices can all use the same editor. Maurice Wuts ------- I have taught quite a few secretaries how to use EMACS, which is the canonical "complicated editor." They were uniformly pretty happy with it. How happy someone is about learning seems quite dependent on the attitude of the person teaching them. I suspect that people who "get overwhelmed" by the number of commands in an editor have had the whole command set laid on them at once quickly by an enthusiast who didn't take the time to describe the philosophy of the command grouping and the framework for using the editor effectively. It is not reasonable to enforce a subset of a complicated editor. This means that someone usually with no view of the application chooses the commands that they think are "simple" and turns off access to anything else. One problem with this is that a programmer's view of simple is not the same as a secretary's view of simple because those people are not doing the same job. A question that beginning secretaries usually ask about EMACS is "how do I move a paragraph". Most of the simplified command sets that I have heard about for EMACS have turned off all of the paragraph handling commands because they are "complicated". In addition you now have created a society where experts use one editor and dummies use its subset. When an expert helps a dummy, they try to use expert commands, which don't work and the expert emits sounds of disgust and annoyance and the dummy feels dumber. None of this sociological mess is reasonable and it can be avoided. Another way of stating the problem with command subsets is that you have placed an arbitrary ceiling on someone else's capabilities. This is unreasonable. The right thing to do is to provide a comfortable growth path for people so that as they become more experienced they can use more complex commands without having to change their view of what the editor is. The EMACS NOVICE library is one implementation of this approach. Rather than removing "dangerous" commands, it redirects them to a handler that explains what the command is and queries the user about whether to do it. This has two benefits. It keeps people from making confusing and drastic mistakes and it gives them a chance to learn from their mistakes. Some people leave most things turned off just to get maximal protection. One favorite is m-ALTMODE, which people leave disabled so that they don't get into the minibuffer all the time by accident when their finger lingers on the ESCAPE key. At least one person I know has become a very sophisticated EMACS user but still uses NOVICE to protect against the unknown. For those who are unfamiliar with NOVICE, it was designed by Richard Stallman and extended and re-implemented by Jan Walker. It is part of the usual EMACS distribution.