C70:editor-people (05/26/82)
>From RWK@SCRC-TENEX@MIT-AI Tue May 25 19:22:34 1982
[Editor's note: I have taken the liberty of appending two related messages
from RWK into this one message. The first message advertises itself as
"flame", but both present a great many important observations. /jq]
I'm getting tired of seeing a barrage of opinions in the form of
dogmatic statements. I think it's about time I make a few strong
statements of my own.
Date: 20-May-82 9:36PM-EDT (Thu)
From: Steve Wood <Wood at YALE>
I have already implemented a change to TOPS-20 that provides a
significant improvement in the interactive response time of a display
editor, while at the same time reducing the number of process wakeups.
It works and is in use everyday here at Yale. My suggestion is that
EMACS could be changed to take advantage of the changes to the monitor.
What would have to be changed?
There should be a one to one mapping between file positions and display
positions. This would require long lines to be clipped instead of
wrapped;
This is completely, absolutely unacceptable. Any editor which hides long
lines is completely unusable in many environments, such as any environment
I've ever been in. Such an editor is BROKEN, a mere fragment of an editor.
The change is also completely gratuitous, since it is quite acceptable to
wake up the editor in this unusual case.
control characters to be displayed as a single high-lighted
character; tabs to be expanded to spaces;
This isn't acceptable either, since EMACS supports that majority of terminals
that don't have highlighting modes. It is also doesn't buy you anything.
If you're really going to do up/down cursorpositioning commands in the monitor
(which I don't think would make an appreciable difference) then just position
it. Let the editor figure out the mapping when it finally gets control and
finds out the new cursor position. Inserting into the middle of the tab
would require the editor to handle it so it could move the cursor before
inserting to the begining of the TAB, but this would be no more disconcerting
than the current TAB behaviour. Actually, maybe it should instead just insert
the necessary spaces actually put it in the place the cursor moved to. THAT
would be an improvement, I think. Converting the file's tabs to spaces and
making the user work with spaces is a fine user-interface idea, but ignores
the reality that the files may NEED tabs for whatever program.
next/previous line and
forward/backward character to move by screen positions and not by file
positions.
They already *DO* work by screen position. What they DON'T do is extend a
line beyond the end. It should be no problem to tell the monitor where the
line ends, if you really wanted to do this.
Would these changes be fatal to EMACS users? I don't see
how as they would only improve what is already a very good editor.
I would refuse to use it. So would a lot of other people, I'm sure. I'd
keep around a non-performance-enhanced version and use that instead.
Many editor designers have taken the attitude that they know better than
the designers of EMACS what an EMACS-child should look like. It has
been my experience that they have often been very, very wrong. EMACS
was in a very real sense designed on the experiences of a very large
community of users, and end up breaking some of the most important
features. This does not mean that an editor has to be identical before
I would accept it. But I do wish people would not start calling
features very many people consider essential "obsolete" and such.
And don't underestimate the importance of compatibility in command
sets. Editor designers don't seem to realize that people who use
their editors use other editors too. I find that all the good ideas
in the world can't overcome an incompatible command set (especially
if the editor isn't extensible enough to fix it!) or a single bad
idea like line-truncation.
So please, I really don't want to hear more about changing EMACS's
COMMANDS to make it easier to implement the monitor.
I think this is more of a TOPS-20 issue than it is an editor issue.
Certainly, if you are only going to try to make improvements in the
performance of a specific editor. I think such an attitude is a mistake
when making changes to an operating system.
It seems to me that you're trying to redesign the editor around the operating
system. This has to be the biggest mistake of them all. I consider the
attitude of "operating system efficience over user interface" to border on
criminal. And all for the sake of optimizing what will be a minor fraction
of the commands -- I can only shake my head in disgust.
----------------------------------------------------------------
Date: 22-May-82 1:24AM-EDT (Sat)
From: Steve Wood <Wood at YALE>
Date: 20-May-82 3:06PM-EDT (Thu)
From: Steve Wood <Wood at YALE>
However the design of EMACS is such that you could not change
the stream editing model that EMACS presents to the user. The
mapping between file positions and display positions is buried
at the lowest level of the implementation. I know this is
true of the TECO implementation and I suspect it is true of
the LISP-based versions of EMACS.
I wish I knew what this meant. If I did, I might be able to tell
you about some of the LISP-based versions of EMACS.
In order to make the mapping between file positions and screen positions
be one to one, the following changes would have to be made.
Unfortunately not all of these changes are not possible using the
extension language and the editor kernel itself would have to be hacked.
First tabs would have to be stored as spaces, by changing the tab
command to insert the appropriate number of spaces instead of a single
tab character. You would also have to hack file input to convert tabs
to spaces. Control characters are displayed as two characters, which
can't be changed without hacking the low level display primitives.
Long lines are wrapped onto succeeding lines. Making it so they are
clipped instead would also require modifications to the low level
display routines. All movement commands could be changed to allow
movement to non-existent file locations, by automatically inserting
enough blanks so that the file does exist at the cursor location. If
you did this, you would have to change the file output logic to remove
any extraneous blanks caused by moving the cursor past the end of a
line or the file, but not making any other changes.
Probably all of this is doable with existing Emacs implementations,
except for the modifications to the low level display routines, as
the redisplay algorithm is not accessable to the user. I don't know
what affect these changes would have on other Emacs commands.
-Steve
Well, in all LISP-based editors I know of, tabs are stored as Tabs.
(Ten-space-wide in Multics EMACS). I went into why this is necessary (we
know why it is unfortunate) in my recent flame. I might try making ^N
do the "right thing" with Tab's in ZWEI (the base for the ZMACS editor
on the Lisp Machine which is also used in a number of contexts which are
not strictly text-editing). I.e ^N would move the cursor to
more-or-less the right place, and if you tried to insert there it would
add enough spaces. The redisplay algorithm is available to the user in
all the Lisp-based editors. (This doesn't mean the code is easily
changable, but any user can replace it in his init or whatever).
I say "more-or-less" because of another problem: The 2-D array of
fixed-width characters model is bankrupt and obsolete. Documents
and even programs make use of fonts of variable widths. TAB's are
not the only character which is of non-standard width! ZWEI tries
hard to move as close to the same vertical position, since the 2-D
array is one of many competing models which are useful to the
user in various circumstances.
The "stream" of characters model that you so despites is another model
which has its own uses. So much so that the Lisp-based editors provide
it to users (in addition to the 2-D array model, the paragraph model,
etc), despite the fact that they do not represent it that way internally
at all. In at least ZWEI and Multics Emacs, text is represented as a
doubly-linked list of lines.
This wealth of different models for the text is one of the things that
makes EMACS so powerful. It also means that optimizing ^N and ^P is not
that important. Look to your M-A and M-E (forward and backward
sentence), your M-B and M-F (fowrdard and backward word) etc. If these
commands cannot respond adaquately fast, I would seriously recommend
against buying that machine. Building them into the monitor is not the
way to go!
What is needed is to optimize the most common ones to minimize the load
on the system. (I've seen somewhere a frequency table of various types
of commands in some EMACS-like editor. My recollection is that C-N and
C-P were down in the noise; I'm sure this is true of my own usage. Does
anybody recall seeing these statistics somewhere?) Echoing and
sequential paging are the only reasonable canidates for further monitor
support that I can believe in without solid frequency-of-use statistics
to back them up.