C70:editor-people (06/01/82)
>From uucp@NPRDC Tue Jun 1 16:42:33 1982
In this note I want to propose a different perspective on the Emacs versus
Yale-Z debate: to advance my view of what the real issues are. I am mainly
offering a framework within which judgements of editor designs might be made,
but at the end I offer an idea that might count as a solution to a lot of
the debate.
1. We have 2 ways of thinking about text (a) Functional: In terms of its
meaning (words, paragraphs, etc. for English; expressions, functions, etc.
for code) (b) Visual: In terms of its 2-D layout on the window or page.
We use the latter for pointing, and often for thinking about the location of
some item. We use the former especially during insertion to decide how to
lay out the material and because our overall goals are largely to do with
the function of the file not its 2-D appearance. This is a dual view;
editors that ignore one aspect will fail to latch on to a significant
portion of the mental representations we use.
2. The converse of the 2-D view of an English text file is not a byte
stream but a word stream. (This is a corollary of point 1.) In text it
doesn't matter at which word boundary a line feed is inserted, but it does
matter if you insert one in the middle of a word. The contrast is between
an editor (mode) that supports 2-D thinking and one that addresses the
meaningful structures, which for English text are words, sentences, and
paragraphs, but for programming languages are things like expressions,
statements and functions. There are of course partial relationships between
the two: paragraphs are separated at line boundaries; programming languages
have strong indentation conventions.
3. In designing an editor, or any other system, we need to compile a check
list of user needs to be supported. (This is NOT the same as implementing a
mode or command per need - see below.) In editors, the following modes seem
needed (these are a user's modes of thought and action: whether they require
distinct command modes is a design issue):
a) English text mode: changes and insertions should cause automatic
filling of lines within a paragraph. There is no return-key function as
such. The space bar is a word boundary key (causing either space or CR-LF).
There should be a sentence-end key (e.g. insert period-space-space), and a
paragraph key. Cursor motion commands should include moving in steps of a
word, a sentence, a paragraph.
b) Program code mode: the idea is the same, the structures are different.
The rules for breaking input into lines are more complex.
c) 2-D mode. This is especially useful for editing tables and diagrams.
There may be two distinct versions. (c1) The user controls divisions into
lines - the linefeed key creates vertical movement - but horizontally
characters are taken literally not interpretatively. Thus tabs are inserted
as single characters, trailing spaces can be added and so on. (c2) Full 2-D
-- the user is concerned to create a 2-D layout, and keys like tabs are
treated like linefeeds as specifying motion. The editor's concern is to
produce a file that represents the appearance of the window; the user
operates only on the appearance and does not think of the characters that
will be used to achieve it.
3.2. There is a further class of user needs to do with getting accurate
echoing and a fast response. Systems that are heavily loaded relative to
the cost of supplying these needs by brute force techniques raise the design
issue of whether to supply them in full and if not then what kinds of
restricted service to supply (e.g. by not updating the screen accurately
during certain modes). There are potential tradeoffs involving fast echo
response and accuracy of the screen representation. For instance speed
could be gained by causing every mid-line insertion to split the line at
that point: the insertion can then continue in the trailing space using
O.S. echoing; reformatting could be done at the end of the insertion. This
would probably be acceptable for English text but too confusing for program
code.
4. As the above suggestion shows, O.S. support for editors in the form of
advanced dynamically changeable remote echoing could be exploited in many
ways, not all of which require a 2-D text model. Although not all editor
behaviour could exploit such support, many could besides the one Steve Wood
favors.
5. A design question quite distinct from the identification of user needs
is that of what virtual machine to present to the user via the interface
i.e. the form in which to present means for satisfying the needs. The
approach that seems to underlie most editors and most of the discussion is
to try to cover all user needs and modes in parallel - to find a single
"right" treatment for tabs, etc. While a single uniform model is
attractive, this does not seem possible in an editor because, as noted
above, we have dual perspectives on the task (2-D/visual versus functional)
Even though Steve Wood emphasized the 2-D perspective presumably the Yale-Z
editor has commands to advance by a word, and presumably it does automatic
line breaks during insertions -- these facilities are in demand but have no
logical place in a 2-D approach. Given user's demands for multiple
perspectives, rather than pursuing a single consistent model it might be
more fruitful to push the notion of modes or subtasks in editing further:
pursue the idea in my previous note of providing disjoint subsets of
commands addressed to separate subtasks -- 2-D movement, structured movement
(by words, etc.), text changes.
This would start with providing a simple command to switch between say,
English, Lisp, C, and 2-D modes. Such a switch would simultaneously change
a number of underlying things: treatment of tabs, of line wrapping, etc.:
it might even cause a re-processing of the current file to do tab
translation throughout. The idea is to make the user conscious that not all
editing is the same task - it depends on the material. Furthermore, it can
depend on the user's view of the task at a given moment. A switch rather
than a disjoint subset may be necessary because of conflicting demands on
certain things (rules for breaking lines, and for what constitutes a word
boundary).
The idea of disjoint subsets can be applied to cursor-key movements. I
believe that their use is in implementing our desire to go from A to B,
where A and B are positions we SEE on the screen. Once we've arrived
however we usually revert to a structural mode of thinking in terms of
words, sentences, etc. My proposal is to copy mouse-based editors. In the
Smalltalk text editor for instance the cursor showing the mouse position and
the one showing the current text insert position are different. To move to
a new position you move the mouse but only when you click a button does the
text cursor move to the mouse cursor. Furthermore, it moves to the nearest
sensible position - and if you point off the end of the line, this will not
be visually close to the mouse cursor but at the end of the last word. If
this separation of pointing cursor and text cursor were adopted in Emacs and
other non-mouse editors, a lot of the debate would vanish. Cursor key
movements would be strictly 2-D, allowing efficient echoing and the desired
regular visual behavior and adjustment to the underlying character
representation would be made only on arrival, signalled by some other key
press. This would decouple the text- to-screen mapping issue from the
cursor-movement representation issue.
I personally would then vote with Steve Wood and against both Smalltalk,
Emacs, and vi and have automatic line-extension done when I point to a space
beyond a line-end. This is easy for an editor to do and, I argue, not
confusing in this model which clearly separates the notion of pointing
cursor from character representation. (The extension would only be done
when the command to equate text and pointing positions was issued). However
under the above proposal, this could be left up to the user as an option, or
done by a separate command. This proposal accommodates both the fact that
there is no such thing as a constant-width set of characters in either old
or new technologies, and the need for cursor key commands to be supported
by regular 2-D behavior of the cursor (this is supported by my experience
of how irritating it is in vi for a downward cursor key command to make
the cursor fly 60 columns leftwards because there is a short text line).
The major problem is that it requires distinct visual representation of
several kinds of cursors. This, my previous note argued, is something Emacs
and other editors already need to display marked positions. If my
hypothesis about the mental distinctness of 2-D and structural thinking is
correct, this is not a serious problem: mark such positions with a character
like '^'. The inaccuracy in line length does not matter from a textual
(structural) point of view, and in cursor-key mode it doesn't matter whether
the displayed characters are textual or not. Of course, such an editor
should support a 2-D mode where there is a strict one-character-per-column
display (and no such cursor characters) for the cases like table editing
where it matters.
Steve Draper
sdraper@yale