C70:editor-people (06/01/82)
>From uucp@NPRDC Tue Jun 1 16:08:54 1982
This note wants to make a point leading to two conclusions:
a) The traditional distinction in the UNIX community between line-oriented
and screen-oriented editors misses the point: the significant differences
between the editors referred to (ed and vi) lie elsewhere.
b) One aspect of the Emacs versus Yale-Z debate concerns insert versus
replace modes. If you believe - very reasonably - that a good editor
exploits our 2-D visual abilities then replace mode should be natural; yet
it seems that many - most? - people prefer insert mode. I offer an
explanation.
--------------------------------------------------------------------------
There is a standard argument in favor of a "cross product" command structure
in editors. In a CPCS, there is one set of command words (nouns) for
objects (e.g. W-word, L-line, S-sentence) and another set of verbs
(D- delete, Y-yank (copy to buffer), C-change, etc.). Together they form a
set of legal sentences e.g. DW, YL etc. Clearly a vocabulary of N nouns and
V verbs gives N+V items to learn but N*V sentences: a great economy in
learning and recall reliability compared to having separate commands for
each combination. In UNIX, vi has part of its command language structured
this way.
However the cross product concept is at the syntactic level: nothing
happens until a whole command (noun and verb) is entered. A more powerful
idea is to implement the concept at the semantic level: you have one set of
commands that select objects, another that operate on the currently selected
object. In this system you would type "WD" or "LY", but the power comes in
that you see the effects of "W" before "D" is executed (the selection is
highlighted, say), you can correct it if it's wrong, you can do "WWWD" to
step along to the word you want and so on. All the advantages of economy
remain, but in addition new sequences are valid, and the user can execute,
check, and correct parts of a hitherto monolithic command.
I believe that this "super" or "semantic" cross product structure is part of
a crucial trend towards splitting actions into small steps, and that this is
important because it allows: errors to be corrected at once rather than
invalidating the whole of a large action, a greater use of visual
feedback, and an incremental, reactive approach to achieving some goal.
It can be and has been carried further. For instance, the selection of an
object can be subdivided into selecting two points (the beginning and end of
it) separately. Emacs supports this with its dot and mark positions.
Mouse-based editors typically have the user select a point and then expand
it to an object.
My claim is that the implementation of this semantic cross product command
structure is perhaps the most - certainly one of the most - significant
aspects of editors.
In UNIX, what is bad about "ed" is nothing to do with the fact that it
displays a line rather than a screen at a time, but is that it allows only
one command (substitute) that compresses into two arguments and a single
action what is better thought of as four separate actions. Ed demands a
command like "s/shuot/shout" to do
1) search forward from the beginning of the line to the start of the first
string "shuot" 2) move a second marker to the end of that string 3) delete
the whole string 4) insert the second argument in its place
It is awkward because you have to give a string long enough to be unique in
the line, even though you only want to change part of it, and because you
can't verify the correctness of the selection before a change is made.
Editors that support a notion of cursor position anywhere in the file are a
great step forward by separating out step 1 from the rest. In UNIX, the
open mode of ex is -- I argue -- a much greater advance over ed than vi is
over ex, even though only the latter is "screen-based."
Similarly the true advantage of mouse-based editors may be not the 2-D
display and the ability to point, but the division of object selection from
command execution. (Emacs is part the way there: you can select regions of
text not just points, but there is not good feedback to show the selection
and this approach is not prominent.)
This view is in opposition to the view that 2-D displays are the crucial
feature of good editors together with command sets that support 2-D thinking
e.g. moving the cursor to a point by motion commands, like cursor keys and
mice, that refer to coordinate positions rather than to text objects like
words, lines, and search strings. I do not think 2-D thinking is a negligible
factor, but I do think that the importance of being able to split actions
into separate steps has been grossly underestimated and that to the extent
they can be separated, the latter is the more important. (It is hard to
separate them because 2-D thinking is not useful without commands that
separate motion from execution: imagine an editor that deleted whatever the
cursor came to rest on! This however is consistent with my claim for the
greater importance of separation.) I have more to say on the 2-D versus text-
structure issue, and on the Emacs versus Yale-Z debate, but it belongs in a
separate note.