C70:editor-people (07/31/82)
>From cbosgd!mark Sat Jul 31 03:12:51 1982
I'm sure we've all heard the complaint that editor X "has too many commands".
(vi and emacs are both subject to this one, and I'm sure others are too.)
I have just made the claim that there is no such thing as an editor with
too many commands (except from the viewpoint of the person who has to
implement it), but rather the problem is that the documentation is so
thick that it's very hard to find the command you really want.
Can anyone make an intelligent refutation of this claim? If there are
other problems with these editors caused by the large number of commands,
I'd like to hear about it.
Mark HortonC70:editor-people (08/12/82)
>From Goldberg@RUTGERS Thu Aug 12 01:53:11 1982
In-Reply-To: Mark Horton's message of 26-Jul-82 1627-EDT
Good documentation of a canonical subset of commands in a program will
certainly help a great deal. Many programs (including the mail program
I am using to send this message) present the first-time user with a
screenful of commands in response to a "?" or HELP command; only a
small subset of these is actually required to perform the basic
tasks the program was designed for.
Despite good documentation, an editor (or any command language for
that matter) that has many commands that a user does not want to
learn at a first sitting can be a problem if it is too easy to
mistype a basic command and end up doing something strange to the
file. It is even worse if the mode changes and the old commands
no longer work. This problem is particularly common with video
editors because they tend to use cryptic commands requiring only
a few keystrokes. As the command language grows, it becomes more
"dense" in the sense that a randomly typed sequence is more and
more likely to be a valid, though unintended, command.
I would argue that an editor with a "dense" command language can
grow to have so many commands that it is no longer easy to learn
to use its basic commands, simply because it is too likely that
the user will type an unknown command with strange side effects.
Bob Goldberg
-------C70:editor-people (08/12/82)
>From GZ@MIT-MC Thu Aug 12 01:59:49 1982
I don't understand, what is the difference between doing
<arg> {move cursor down five lines} <lDelete>
and doing
<set-mark> {move cursor down five lines} <Kill Region>
(aside from the fact that you can probably do a lot more things after a
<set-mark> than after an <arg>) ?
If I guess right at what the "l" in lDelete stands for, you also need
<charDelete> and <wordDelete> and <pageDelete> and <s-expressionDelete> and
<C-statementDelete> and .... How is that limiting the number of commands? With
Set Mark and Kill Region, you have all of those via a simple and consistent
mechanism. But Kill Line et.al. exist and are heavily used despite that fact,
which would seem to indicate that they are not a great burden on anyone's
memory, and that users will opt for convinience over elegance.
I think that indeed there is a certain learning difficulty with any editor
which can *DO* a lot of things. But I doubt whether this is directly related
to the structure of the command language. It's probably an individual thing - I
personally have an easier time learning simple associations than syntax, i.e.
I prefer to memorize ^K=kill line, ^W=kill region, over memorizing rules for
command arguments and qualifiers and modifiers and what not, no matter how neat
the designers think those rules are. But I'm sure there are other people who
are more comfortable with lots of syntax. Probably an ideal editor would
provide both.C70:editor-people (08/12/82)
>From JWalker@SCRC-TENEX@MIT-MC Thu Aug 12 03:07:25 1982
From: Maurice J. Wuts <WUTS at USC-ECLC>
To: 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.