C70:editor-people (05/26/82)
>From GZ@MIT-MC Tue May 25 18:05:21 1982
The question of abstract models aside, it seems to me that in practical terms,
you are proposing only a few things different from the way Emacs works.
1) The user doesn't (need to/have to) manage formatting characters explicitly.
Things like trailing white space and tabs are taken care of by the editor,
with some appropriate semantics (e.g. automatic extension at end of line
due to cursor motion, automatic deletion when writing to file)
2) Truncation and horizontal scrolling as the preferred mode of viewing long
lines.
3) Overwriting as the preferred mode of editing.
I think 1) is perfectly reasonable. Somebody should implement this for emacs
(you only need ^R Up Screen line, ^R Down Screen Line, etc. and a save-file
hook). (Actually, tabs are useful in retaining their tabbing property when
editing tables, but in most free-form text their presence is incidental
anyway, due to the use of higher level formatting commands)
2) is a reasonable option. I would like to see it added to Teco, or to future
implementations of Emacs. It is probably preferable when viewing text with
some "columnar" properties, such as a compiler listing. However, when what you are viewing is strictly left-to-right, such as English text, I don't think
cutting it off and forcing the user to shift the whole screen left and right just to maintain the natural flow of the text is reasonable.
As for 3), all I can say is I've used both, and, except for making pretty
pictures, overwriting is a total loss. It forces you into a line-editor mode
of thinking, counting characters and all. No amount of improved efficiency is
worth the price. You admit as much yourself, by saying that in most editing
situations, you place the user in insert mode automatically.
Finally, I think you got it backwards when it comes to words like "obsolete".
Regardless of whether the model you present is better or not, it is older than
emacs. It is the model used by IBM screen editors. In fact, they go you one
better, efficiency wise... Instead of putting the support in the monitor,
they put it in the terminal. Simple cursor motion, overwriting and even
inserting characters is instantenious regardless of system load. Of course
you will wake up the editor in more situations (I guess most control
characters and on attempts to go off screen) while they only wake up the
editor on ten or so keys (ENTER and the PF keys). But then one would expect
SOME progress in 10 years.C70:editor-people (05/26/82)
>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
-------C70:editor-people (06/10/82)
>From Goldberg@RUTGERS Thu Jun 10 00:35:54 1982
Date: 24-May-82 12:51AM-EDT (Mon)
From: Steve Wood <Wood at YALE>
Subject: Re: Improved support for Emacs in TOPS-20.
... 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. ...
I fully agree with this statement, and I would extend it to
editors in general, not just display editors. In fact, the following
statement appears in my Dec. 1981 Ph.D. thesis on distributed editing
architectures (which has not yet been sent by Rutgers to University
Microfilms, grrrr):
Text editors are of greater importance than generally
recognized. They are arguably the most important class of
programs in existence, because of their central role in any
application, and because of the amount of time people spend
using them. Computer Scientists have studied the design
of operating systems and programming languages in great
detail, but have generally regarded text editors merely as
utility programs. In reviewing the literature on the subject,
one finds that very little has been written beyond broad
surveys of existing software, and almost no analysis has been
done of the design decisions faced by the implementor of a
text editing system.
I have nothing to add to the discussion of editor user
interfaces, and in fact quite pointedly avoided that issue in my
thesis, beyond asserting that a good architecture should allow any
reasonable user interface. Building some restricted interface into
TEXTI violates this principle, though I suspect that a few of the
more common editing situations (such as adding text to the end of the
file or line) could be optimized in a given editor using some suitably
designed jsys. Indeed most timesharing editors go to some pains to
optimize normal insertion of characters at the end of a line as a
special case (including, I believe, TWENEX EMACS).
I see two consistent themes in the correspondence here:
1) dissatisfaction with the editing response on a timeshared host, and
2) the desire to have one's preferred user interface and file model.
One contributor suggests that we all buy powerful single user systems
and use timeshared hosts as file servers, etc. That is fine if you
can afford it. Perhaps the cost of powerful single user systems will
fall enough in 5 to 10 years so that this may be an option to more
than an elite few.
In the mean time, given the economic reality faced by most of
us that says we must use a timeshared host as both the file server and
file processor for compilation, text processing, etc., I suggest that
an editor distributed between the host and a dynamically programmed
terminal/microprocessor does a good job of addressing these two
themes.
In terms of the alternatives raised by the correspondents
of this mailing list, what I propose (as *one* alternative, not the
*only* solution, mind you) is to handle most of the local cursor
movements, insertions/deletions, local searches, etc. in the local
terminal+processor itself. Simulating one possible scheme for doing
this, I found that the average editing session at Rutgers would
require on the order of only a dozen user-observable host wakeups (the
rest would occur in the background, and there would be many fewer
total host wakeups than user keystrokes).
Note well that the local terminal+processor interface would
have to be written to communicate with a specific program on the
host, assuming the same file model as the host editor server with
which it communicates; an IBM block mode style "general editing
terminal" is totally inadequate unless one does not care what the user
interface looks like.
A further benefit of this approach is that the effective rate
of communication between host and screen can be made much higher than
the actual connection bandwidth, through judicious saving of
previously displayed text and predictive background fetching of the
"next" screenful. In fact, much of the time the window motion would
not require host communication.
The performance claims I make here are backed up by hard
evidence in my thesis, from analysis of 15,000 actual editing sessions
using a variety of editors, and through simulations of proposed
schemes using the file-reference data obtained during these sessions.
Let me apologize again for the bureaucratic snail's pace at
which Rutgers University's thesis handling office crawls. I asked
the University to send out some copies to some of you (did anyone get
one yet?) and hope to have it made available though University
Microfilms for the rest of you. Unfortunately, the heart of the
work is the editing session analysis, which I have summarized in about
50 plotted graphs and figures, so electronic distribution is not
feasible.
Bob
-------C70:editor-people (06/12/82)
>From POURNE@MIT-MC Sat Jun 12 01:25:37 1982
I quite agree and am delightedly surprised to discover
others believe the editor to be if not the most important class
of software, certainly among the top ones.
However: I wonder about the remark implying that
distributed computing (lots of small computers, one to each
user, with a net to share big peripherals) is all that
expensive. Is it? A full micro with every bell adn whistle I
can imagine (except no hard disk and no printer) cannot cost
more than $4000 in any quantity. Now true: this doesn't include
a terminal, or else one compromises the micro for the price;
But the micro can be a terminal with a video board and a monitor
and a keyboard; in the early days of micros that was the best
way to go for the money.
Not being a programmer by trade, I don't know how
distracting it is to have to wait long after typing so see it
appear on the screnn; but that is the death of creative writing,
I think, and is one of the major reasons I no longer compose
computer articles on the net (even though doing so got me a lot
of good comments the couple of times I did it).
Perhaps I haven't said anything that isn't implicit in
your piece: it does seem to me that ditributed computing is
preferable to the time-sharing notion.C70:editor-people (06/15/82)
>From Goldberg@RUTGERS Tue Jun 15 02:28:29 1982
A $4000 micro would serve certain functions fairly well in a
distributed environment, such as supplying the user interface
to a text editor/processor. But machines in that class would
not satisfy the computing needs of most users of large timeshared
machines. Larger machines, such as those based on the Motorola 68000
cpu have greater potential to fill this need, due to their large
address space. However, when you add the necessary peripherals
to make an independent computer, they get much more expensive than
$4000, unless you are satisfied with slow disks and a small physical
RAM.
If an appropriate Ethernet connection is available, it may be possible
to use some sort of shared disk server to reduce the price of the
individual machines, which now don't need as fancy (or possibly any)
disk. However, this configuration is then distributed and not a
stand-alone micro.
Bob
-------
[ Editor's note: I think that comments about distributed vs. standalone
word processing systems that focus on hardware considerations would
probably fit better on WORKS rather than EDITOR-PEOPLE, though I will
continue to publish submissions on the topic as long as they do not
completely duplicate WORKS. If you are interested in discussion of work
stations, send mail to PLEASANT@RUTGERS asking to be included on the WORKS
mailing list. /JQ ]