From: utzoo!decvax!ucbvax!C70:editor-people
Newsgroups: fa.editor-p
Title: Re: Improved support for Emacs in TOPS-20.
Article-I.D.: ucb.1182
Posted: Tue May 25 22:55:27 1982
Received: Sat May 29 03:25:09 1982

>From Wood@YALE Tue May 25 22:41:52 1982
Now that the shelling has died down, here is my reply to all the
messages I received in response to my flame.  First let me apologize
for the ad hominem remarks in my original message.  They were gratuitous
and resulted in misunderstandings about the points I was trying to
make.

Many people felt that the following statement was an insult to the
entire academic community:

    "The fact that EMACS is so widely used within the academic community
     reflects the current lack of knowledge about display editing as
     much as it reflects the virtues of EMACS."

That was not my intention.  I could have said "lack of research", but
it amounts to the same thing.  The design of a display editor is at
least as important as the design of an operating system or programming
language, yet the amount of published research about display editing
pales in comparison to the latter two subjects.  Most of what has been
written consists of general surveys of existing software.  Very little
has been written about what the issues are in the design and
implementation of a display editor.  Anyone who has written an editor
knows what some of these issues are from painful experience, but that
experience has to be published in order for others to learn from it.

I was not trying to convince people that a 2-d model is "better" than
a 1-d model.  My point is that the 2-d model is as valuable as the
1-d model, and that the editor should be able to provide both.  I feel
that the 1-d model of Emacs is unnecessarily restrictive because it
precludes the possiblility of a 2-d model.

It is unclear to me what Emacs users feel is important about the 1-d
model.  Is it not allowing the cursor to be positioned at a point where
the file does not exist?  This strikes me as a side effect of a decision
made in the underlying implementation and not a feature that is
intrinsically valuable.  Or is the ability to manipulate a continuous
stream of text, including any intervening line breaks?  This is what
I think is important about the 1-d model and what must be provided
by any 2-d editor.  The Z editor presents a 2-d model that allows the
user to select contiguous lines of text and rectangles of text.  The
Z editor presents a 1-d model in that the user can also select a
continuous stream of characters, including line breaks.  The 1-d model
has no affect on the 2-d motion of the cursor keys.

About my criticisms of the semantics of the next/previous line and
forward/backwards char commands in Emacs, several people responded
by saying that they move by words, sentences, and paragraphs, and that
the line/char motion commands are not that important.  My response
is that both types of motion are equally important but that in Emacs
the line/char motion commands are second class citizens.  For example:
suppose I am reading text on the screen and see a word or phrase that
I would like to change.  My goal is to get to the location of the change
quickly and with as little mental effort as possible.  Ideally I am
in the cockpit of an F-16 fighter and the computer watching my eyeballs
moves the cursor for me as soon as I have focused on the spot I want
to destroy.  Lacking the ideal solution then I would like to use
whatever pointing device my display terminal has to offer, because
a pointing device allows me to look at the screen and let my hand do
the rest.  The semantics of the line/char motion commands in Emacs
prevent me from doing this WELL as they do not always move in a linear
fashion.  The slow response time only aggravates the problem.

Some may argue that the cursor keys on most terminals are not a pointing
device, and this is true for poorly designed terminals such as the
VT100 (bad layout and very slow autorepeat rate).  But on the Datamedia
1521, the cursor keys are a poor man's mouse and it seems unreasonable
that the design of Emacs should prevent me from using them as such.
Designing the editor to take advantage of the available hardware seems
perfectly reasonable.  If you have a bit-map display with a mouse,
are you going to let it sit idle?  I think not.  If Xerox or someone
else starts marketing a cheap optical mouse, then it would be reasonable
to install one on an ASCII terminal by having it send cursor motion
commands to the host, provided the host can echo the commands in real
time.  Some of the larger ASCII display terminals, such as the Ann
Arbor Ambassador with its 48x80 display, would benefit from having
a mouse.

The question of insert mode versus replace mode is a non-issue, as
the editor should provide both and let the user decide what he wants.
There is nothing about the 2-d model that favors replace mode over
insert mode.  I was wrong to say that the 1-d model favors insert mode,
as several people pointed out.

The idea of a canonical text file format seems to have been
misunderstood.  I am suggesting that a reasonable default is for the
editor to convert tabs to spaces; trim trailing blanks and trailing
blank lines; and insure that every line ends with a newline sequence.
The reason for these rules is that all of these situations are not
visually apparent to the user, other than by moving the cursor over
a location that violates one of the rules.  The need to generate files
for the occasional program that requires files with such characteristics
is not a reason to sacrifice the default, but rather a reason to add
an escape to the default that lets the user handle the situation,
possibly in a less graceful manner.

I have avoided talking about performance issues or monitor hacks so
that people will not get the mistaken impression that I think the design
of the user interface should be driven by performance considerations.
On the other hand, the issue of poor response time cannot be ignored
if it renders the cursor keys useless as a pointing device and forces
the user to move in a manner more clumsy.

Other random points:
    Z will run on the distributed TOPS-20 monitor, but with response
    time similar to Emacs.

    Z does not require the use of special ASCII terminals, as the user
    is free to rearrange the keyboard any way he wants.  Each command
    can be assigned to any input sequence from 1 to 4 characters in
    length.  Z currently has terminal capability files for the
    following:  Datamedia (15xx, 30xx), Ann Arbor Ambassador, VT52,
    VT100, TVI9nn, Z19, and HP2621.

    Z is a production editor, used by over one thousand users at Yale,
    including secretaries, business students, and system hackers.  It
    is fully documented, including a reference manual, on-line help,
    and a tutorial walk-through file.  Z can be accessed by all users
    on the system, most of whom use 9600 baud terminals.

    There may have been valid reasons for including certain jsyses
    in the monitor when TENEX was developed.  I think those reasons
    no longer apply and should not be used to justify adding
    functionality to the monitor that can just as easily be implemented
    as a user library that is easily accessable for fixing bugs and
    making enhancements.  The COMND jsys already has enough "virtual
    terminal support" to handle RUBOUT, ^W, etc. The only improvement
    I can suggest is adding system calls to allow new terminal types
    to be defined without having to rebuild the monitor, as is currently
    necessary.

-Steve
-------