From: utzoo!decvax!harpo!npois!ucbvax!C70:editor-people
Newsgroups: fa.editor-p
Title: Re: evaluating editors
Article-I.D.: ucb.1272
Posted: Fri Jun  4 03:37:36 1982
Received: Sat Jun  5 01:30:26 1982
Reply-To: ople

>From gaines@RAND-UNIX Fri Jun  4 03:32:14 1982
Since I have been associated from the beginning with a family of related
editors, it seems appropriate for me to discuss some ideas in the context
of the history of those editors.  The daddy of them is an editor developed
by Ned Irons in 1967 at the Institue for Defense Analyses (IDA) in
Princeton.  Ned designed and implemented a timesharing system for the CDC
6600, and as part of it designed what we at the time called a "full screen"
editor, to distinguish it from line-at-a-time editors.  The decendents of
this initial editor include E at Yale (where Ned went in 1969), NED at Rand
in 1964 (guess where the name came from) (done by Walt Bilofsky, now the
Software Toolworks), and (as a copy of NED) the Apple Pie editor.  Dave
Crocker worked briefly extending NED while he was at Rand, but the real
extensions which transformed it into the current E editor from Rand were
done by Dave Yost.  The lastest version, with really quite a lot of
goodies, is E15.  Those who want information about it should contact Mike
Wahrman .

The original editor had very little: forward and back a page (screen) or
line, cursor movement and insert.  Ever heard of insert?  It didn't mean
insert mode, in contrast to overwrite mode.  The controller for the
terminals available in 1967 required a separate function key that was
interpreted to mean that the screen was now correct, and therefore could be
inserted in the file.  The individual keys were not passed back to the 6600
as each character was struck.  Instead the refresh memory (stored in the
controller, which supported several terminals) was modified.  I mention
these details because the hardware strongly colored the model of editing
that evolved.  The hardware made it essential to view the screen as a
blackboard with a little peice of the file on it.  The non-function keys
and the cursor control buttons allowed one to rearrange his little
blackboard, and then later indicate by hitting "insert" that this was how
the file being edited should now be updated.

The terminals were specially modified to have many function buttons, and as
time went on new functions began to be added to the IDA editor.  However
they never included an insert mode capability, since the hardware couldn't
support it.  Thus the intial orientation of this class of editors was
determined.

As an aside to a discussion of purely editor matters, in the IDA system the
command executive was invoked from within the editor, and as a consequence
the system had some very pretty aspects.  Until I saw the Multics command
executive being invoked from within EMACS, I was not able to find another
system that could provide some of the nice effects that this permits.

As I said, Irons' initial editor didn't have very much.  But you could get
a lot done.  Almost immediately, though, Franz Djorup (still at IDA)
started extending the editor.  Eventually he and Irons published a paper in
CACM (early 1971, I believe).  The great leap forward was the invention
"pick" and "put" (sugggested by Bob Cave, who is also still at IDA).  In
this class of editors "pick" and "close" copy lines to a temporary buffer
("close" also deletes them from the file) and "put" copies these lines from
the buffer to a designated point in the file.  Before these came along,
various attempts to write programs that would rearrange a file in a nice
way were tried, all almost unuseable.  The capability to rearrange a file
by marking sections, together with the ability to move a cursor around the
screen, are among the prinicipal elements that make editors powerful, in my
view.

The Yale E editor had some extensions from the IDA editor, and some
changes, but retained the flavor of the IDA editor.  I have not seen it in
10 years, and don't remember its details, but I recall noticing at the time
that the most striking differences bore a relation to the hardware being
used (the PDP 10 running TOPS 10, and the funny terminals Irons found --
made by Sugarman, I vaguely recall).  Insert mode was possible with that
system, I think.  Someone with more experience may wish to comment on the
major features in E that differ from the IDA editor.

The major advance made by Bilofsky was to free the editor from line size
limitations and to permit the use of several windows on the same CRT.  This
required dealing with issues such as what to do when the two windows were
displaying some or all of the same section of a file, and a change was made
in one window.  Bilofsky also added the capability to execute a command
from within the editor, possibly sending a marked block of the text being
edited as input to the command.  This was doable with reasonable effort
because of Unix pipes and the way the Unix shell works.

The E15 editor of Dave Yost is Bilofsky's NED in spirit, but reworked from
the ground up.  Many new features have been added.  Everyone seriously
interested in editors should look at it just for the range of ideas it
displays.

I haven't seen the Yale Z editor, but I would suspect derives from the
editors already mentioned.  Various people were going back and forth
between Yale and Rand during the 1970's, including Ned Irons.  Again,
others familiar with it may wish to comment.

With the Rand editors, the model I described above has changed slightly.
Now a better model is that the editor supports a workspace that extends
indefinitely to the right and down, and that may be initialized with the
contents of a file.  The screen is a window into this workspace.  The user
can position his window to display any portion of the workspace, and can
move his cursor where he will within the window.  For activities that do
not involve insertion of characters, the analogy of a blackboard that
extends indefinitely to the right and down is quite good.  Insertion of
lines, characters, or blocks (multiple lines or line fragments) cause
immediate movement down or to the right of some of the blackboard.  One
need not, when using a blackboard, explicitly supply white space (black
space??).

The E15 editor embodied so many features that I though it was getting to be
about as good as one could expect in an editor.  Then I saw EMACS.  It was
a surprise and a delight to me as a computer scientist.  I found the idea
that one could build in some knowledge of the domain of the text being
edited very exciting.  This clearly is a step in the direction we keep
striving to go with computers: reduce the work of someone using a computer
by having it do as much as possible under the user's control.  Furthermore,
the fact that to a degree it is possible to build in additional knowledge
is another large plus.

Having seen EMACS, I got another suprise when I saw my first good word
processor.  While not extensible as EMACS is, knowledge of some nice
aspects of printed language are built into the best of them that do not
appear in general-purpose editors.  A real effort has been made in them to
follow the idea of "what you see is what you get", in contrast to the edit
+ nroff approach in which most special formatting is simply described for a
later pass through a formatter.  There is a limitation, though, to the
"what you see is what you get" approach: terminals cannot display what can
be printed.  This is true at the top end of the quality scale, in that
typsetters and printers can do things that even the high resolution bit-map
terminals being offered today cannot do.  It is also true on a relative
scale; the cost of good display quality terminals is high relative to the
cost of printing equipment for organizations that need lots of terminals.

In closing this note, I would like to make some comments about the 2D
versus 1D debate that has been going on.  The model I have described above
is a slight extension of the 2D view.  It seems to me that this model is
more general than the "edit-the-file" model (I don't think the term 1D is
very descriptive of what goes on in EMACS).  It seems to me that the cases
when one must append white space at the right end of a line or after the
last line in a file are so rare that it is best taken care of by a file
reformatter, and that aside from this capability the "indefinite
blackboard" model gives the user more power than the edit-the-file model,
while giving up nothing else.  Certainly it is nice to be able to position
the cursor by reference to the semantic constructs the editor has been
taught to recognize.  But as when making marks on a real blackboard, it is
also nice to be able to get to a point in the workspace independently of
these semantics.  I think the edit-the-file model is simply restrictive to
no significant advantage.  Unfortunately, at least in the LISP version of
EMACS on Multics, I don't think it is changeable through EMACS extensions,
but rather would require major surgery.  Those who only have familiarity
with the edit-the-file model should take a look at the many goodies related
to the indefinite blackboard model Yost has built into E15 to see how much
power that model really has.