[fa.editor-p] evaluating editors

C70:editor-people (06/01/82)

>From reid@Shasta@Sumex-Aim Tue Jun  1 12:28:30 1982
The issue of getting users for text editors, and of Yale's isolation,
is important, and I'd like to comment on it a bit.

In this systems business of ours, it is extremely difficult to evaluate
the quality of a piece of work. There are no mathematical proofs to
read through, no pages of data and graphs to peruse, no airtight
physics experiments that can be run to check hypotheses. Instead we
rely on our designers' instincts, evaluating systems as we explore
them. If a system is good, we might use it, steal its ideas by copying
it, rave about it to our friends, or even in some cases abandon
everything we had been doing to make the incompatible change to the new
system. If a system is bad, we might ignore it, poke fun at it, flame
at how ignorant it is, or perhaps try to evaluate why it is bad so that
we (collectively) do not make that mistake again. Sometimes systems are
bad because they are based on bad models; other times they are bad
because they are programmed badly; perhaps they are bad because they
are internally inconsistent. There are many reasons that systems can be
good or bad.

In about 1976, or thereabouts, we at CMU (where I was at the time) got
a copy of the source and documentation for the Yale Editor "E". Craig
Everhart and I struggled valiantly to get it running, and after burning
the better part of a month on it, we gave up. It was written to run
under Tops-10, but it assumed the existence of very extensive changes
to the monitor, including the dreaded SCNSER. It was politically
unacceptable at CMU to make such major and incompatible changes to the
monitor, and it just wasn't going to work without them, so we stopped.
"E" also was written to use a particular terminal (I forget the brand)
and no other, but the manufacturer of that terminal had gone out of
business. So we couldn't even dial Yale long distance and use the
editor over the phone: we didn't have the right brand of terminals. So
despite our interest in exploring this interesting-looking editor, we
were not able to evaluate it properly because we could not use it.

At about that same time, give or take half a year, the EMACS editor
started appearing on TOPS-20 systems around the network. I had access
to SRI-KL, and EMACS supported all of the various terminals that were
around. I was able to use EMACS, learn it, and assimilate its ideas.

Naturally I think that EMACS is the better of the two editors, because
I was able to use EMACS and not just hear about it. When I teach
students about text editors, I include the EMACS model of editing as a
major focus, and I don't even mention the existence of either "E" or
"Z" from Yale, despite my beliefs that they might actually be good
editors.

Now my primary computing comes from a VAX Unix, Shasta, and on that
system we can run three worthwhile editors: Jim Gosling's EMACS, Rand's E
(a.k.a. NED), and Bill Joy's VI. I don't know who at Rand is the main
force behind E. And as I think and talk about editors, it is very
convenient to be able to draw examples from these three working models.
 From what I've heard about Yale's Z, its editing model is fairly
similar to Rand's E, but since Rand's E is exportable and fairly
universal, while Yale's Z is not, I will probably end up associating
and attributing those ideas to Rand and not to Yale.

The moral of my ramble is this: if what you are trying to do is to
write a good editor for your own people to use, then you are free to do
whatever you want. If what you are trying to do is influence the
opinion of the C.S. research community, and hence the directions and
ideas of future editors, you have to make your system available to them
to be evaluated. These people are not fooled by rhetoric nor persuaded
by hearsay.

Brian Reid

C70:editor-people (06/01/82)

>From reid@Shasta@Sumex-Aim Tue Jun  1 16:07:50 1982
The issue of getting users for text editors, and of Yale's isolation,
is important, and I'd like to comment on it a bit.

In this systems business of ours, it is extremely difficult to evaluate
the quality of a piece of work. There are no mathematical proofs to
read through, no pages of data and graphs to peruse, no airtight
physics experiments that can be run to check hypotheses. Instead we
rely on our designers' instincts, evaluating systems as we explore
them. If a system is good, we might use it, steal its ideas by copying
it, rave about it to our friends, or even in some cases abandon
everything we had been doing to make the incompatible change to the new
system. If a system is bad, we might ignore it, poke fun at it, flame
at how ignorant it is, or perhaps try to evaluate why it is bad so that
we (collectively) do not make that mistake again. Sometimes systems are
bad because they are based on bad models; other times they are bad
because they are programmed badly; perhaps they are bad because they
are internally inconsistent. There are many reasons that systems can be
good or bad.

In about 1976, or thereabouts, we at CMU (where I was at the time) got
a copy of the source and documentation for the Yale Editor "E". Craig
Everhart and I struggled valiantly to get it running, and after burning
the better part of a month on it, we gave up. It was written to run
under Tops-10, but it assumed the existence of very extensive changes
to the monitor, including the dreaded SCNSER. It was politically
unacceptable at CMU to make such major and incompatible changes to the
monitor, and it just wasn't going to work without them, so we stopped.
"E" also was written to use a particular terminal (I forget the brand)
and no other, but the manufacturer of that terminal had gone out of
business. So we couldn't even dial Yale long distance and use the
editor over the phone: we didn't have the right brand of terminals. So
despite our interest in exploring this interesting-looking editor, we
were not able to evaluate it properly because we could not use it.

At about that same time, give or take half a year, the EMACS editor
started appearing on TOPS-20 systems around the network. I had access
to SRI-KL, and EMACS supported all of the various terminals that were
around. I was able to use EMACS, learn it, and assimilate its ideas.

Naturally I think that EMACS is the better of the two editors, because
I was able to use EMACS and not just hear about it. When I teach
students about text editors, I include the EMACS model of editing as a
major focus, and I don't even mention the existence of either "E" or
"Z" from Yale, despite my beliefs that they might actually be good
editors.

Now my primary computing comes from a VAX Unix, Shasta, and on that
system we can run three worthwhile editors: Jim Gosling's EMACS, Rand's E
(a.k.a. NED), and Bill Joy's VI. I don't know who at Rand is the main
force behind E. And as I think and talk about editors, it is very
convenient to be able to draw examples from these three working models.
 From what I've heard about Yale's Z, its editing model is fairly
similar to Rand's E, but since Rand's E is exportable and fairly
universal, while Yale's Z is not, I will probably end up associating
and attributing those ideas to Rand and not to Yale.

The moral of my ramble is this: if what you are trying to do is to
write a good editor for your own people to use, then you are free to do
whatever you want. If what you are trying to do is influence the
opinion of the C.S. research community, and hence the directions and
ideas of future editors, you have to make your system available to them
to be evaluated. These people are not fooled by rhetoric nor persuaded
by hearsay.

Brian Reid

C70:editor-people (06/03/82)

>From Mishkin@YALE Thu Jun  3 01:14:55 1982
I fully sympathize with your painful experience trying to bring up
bogus software.  In case it is still not clear:  Z runs on unmodified
TOPS-20 systems as well as on our own modified monitor.  I completely
agree with you that exporting (or "exporting") software which has
bizarre monitor dependencies is totally unacceptable.

I can not comment on earlier generations of Yale hackers from which
the present Tools (incl.  Z) work is totally divorced.  However, we
have strived very hard to make our software robust and exportable.
Every single tool we send out is documented.  All our code is written
in a high level language (Bliss; higher than MACRO anyway) and uses
a shared runtime library.  Z is terminal independent and it is very
easy to add new terminal types to Z since it uses a termcap-like
facility (i.e. it uses terminal descriptor files).

In characterizing our "isolation" I should have mentioned that, to a
certain extent, in retrospect we consider this a boon:  had we been
on the net, we probably would have absorbed that large set of random
programs written in MACRO instead of developing a coherent set of
utilities and a environment for writing them.

                -- Nat

C70:editor-people (06/04/82)

>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 <Mike at Rand-unix>.

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.