C70:editor-people (05/27/82)
>From C70:daemon Thu May 27 01:08:32 1982
I have just reviewed the set of messages that have been flying over
TOPS-20 and E-P. I am afraid things got really out of hand. A little
background is in order.
At Yale, for better or worse until recently we were isolated from the
rest of the TOPS-20/Emacs world and hence developed a lot of our own
software. We have a slightly different (note I didn't say "better")
tradition of screen editors. Yale editors have stressed aspects of
editing different from Emacs. We do not consider ourselves amateurs
on the subject of editors and resent the attitude that "Emacs has solved
all these problems and why are you telling us about your bogus editor".
The basic style of Yale editor has been in use here for 10 years; people
like it. The current Yale editor, Z, has been in serious, production
use for several years.
I would like to think that discussions about differences between Z
and Emacs could be to each's benefits. Let's not all get our defenses
up so high that we can't learn from each other's experiences. Please
do not take any mention of problems with Emacs as an all-out attack.
If some of our messages have sounded a bit extreme it is only because
being in a minority we feel we have to speak strongly so people will
notice our alternatives. Despite this, I think some people reacted
over-defensively to Steve Wood's first message.
At Yale, only 2 people out of a community of hundreds of users use
Emacs over Z. This is not to denigrate Emacs; Emacs is a very
good editor and has many features Z lacks (note also that Z has features
that Emacs lacks). My point is that we should all have realized that
arguments of the form:
(Editor X has n-hundred users & has feature Y) =>
(feature Y must be necessary for a good editor &
any editor which doesn't have it must clearly be inferior and useless)
are just not credible. People use all sorts of editors for all sorts
of reasons not necessarily having to do with the quality and features
of the editor compared to other editors (e.g. it was the first one
they learned; it is the one that is supported best at a particular
site; use of other editors is socially frowned upon). We all know
this, don't we? I am not ashamed to say that a main reason Z is used
most heavily at Yale is because it was here first, and is well-supported
here. I would be hard-pressed to believe that the Emacs story is much
different at the sites at which it is used. I don't think anyone has
the ability to fully factor out the incidental reasons for a particular
editor's use in judging an editor's quality. Thus, I think for the
purposes of electronic forums I think we would do well to stay away
from issues of features near and dear to various people's hearts
(believe me -- I am probably as grossed out by lines being wrapped
at the right as you are about their being invisible off the right;
what does it prove? I believe you when you say you like wrapping better
and I would hope you would respect my preference).
The core of the original discussion was monitor support to improve
the performance of editors. My reaction to the proposed TEXTI changes
is that people were not thinking about the more global issue: how
does the implementation and user interface of an editor affect the
kinds of things one might reasonably consider adding to an OS to
increase the performance of the editor? That is, if you are interested
in improving performance, when do you consider changing editor styles?
Or to put it another way, when do you not bother to not strive for
the last iota of efficieny in an editor that has design properties
that prevent significant optimization along a particular dimension?
Subtract out any parts of Steve Wood's message that you might find
offensive and what you have is not an attack on Emacs. Rather you
have a statement that says: look what different (and hopefully more
extensive) kinds of support you can give to an editor if it has a
particular model. Whether you like the style or not is another matter.
Suffice it to say that some large number of people like the Yale-style
editor enough that someone (Steve) considered techniques to support
it in the OS, then implemented those techniques and got a significant
win out of it. This information should be added to the editor
designer's bag of information he uses when building editors. It is
up to him to evaluate the model AND the efficiency of implementation.
Say, if he (and his user community) are ambivalent between the 1-D
and 2-D models he can use this piece of (dare I say "experimental")
information to help in making his choice about which model to use.
-- Nat
-------C70:editor-people (05/28/82)
>From RWK@SCRC-TENEX@MIT-AI Fri May 28 00:56:34 1982
I don't think you need to defend Z much. I think all the roasting was
due to Steve Wood's outrageous claims that the so-called 1-D model of
editing was "obsolete". I admit to having borrowed that word in some
replies with satirical intent, and that was probably gratuitously
inflamatory.
I saw Z today for the first time, and was impressed by many things about
it. I still wouldn't want to use it for editing text, but I sure would
prefer it (assuming I knew the command set, etc.) for editing tables,
pictures, etc. And in terms of making use of things on the screen in
commands, such as searches and file-loading, it was superior in several
instances to ZMACS, the EMACS decendant editor on the Lisp Machine.
This led to users new to the Lisp Machine to expect a number of features
which we have only recently begun to address in earnest. That Yale has
been isolated was obvious, yet that hasn't stopped them from coming up
with a different set of clever ideas. Unfortunately, I ran out of time
so I did not get to talk to Steve Wood, as I had hoped. Sorry to have
missed you, Steve; some other time, perhaps.
I have espoused the idea from time to time that no single model is
adaquate for a text editor, that you may want to deal with various
abstractions in your text editor. In comparing how one Z user did
things vs. how I do the same things, the Z user would use a high-speed
repeating key to do X and Y movements, where I would typically use
various commands which were based on what I was editing. The Z mode of
use is clearly much easier to learn than my mode of use. It does not
follow from this, however, that Z is significantly easier to learn;
begining ZMACS users typically make much heavier use of the mouse as a
pointing device and never learn the keyboard techniques that I have
developed since the days of TECMAC (an EMACS predecessor). Since my
intent was to help with ZMACS rather than explore Z, I can't make any
real comparison as to the wealth of features provided, but I wasn't
shown any commands which understand program indentation and things like
that. In fact, I wasn't shown anything like word-commands. My favorite
EMACS command is Meta-Rubout, which kills the word before the cursor.
Just the thing for badly misspelled words! Does Z have these things?
Do people use them? Or do Z users just make use of the fast repeat
keys?
There is something to be said for a single, uniform, simple model, in
that it produces something which can be learned in a very short time.
If your initial learning effort is a major part of the total effort, as
in something that will only be used casually, then that can be an
overriding factor over total functionality. There is a subset of the
EMACS command set which is like this, which I show to casual new EMACS
users. I suspect I was being show a combination of those features and
some flashier ones meant to challange ZMACS. If there is a Z document
I would be very interested in seeing it.
In reply to your (Mishkin) message, I stand by my claim that and editor
which only truncates lines is completely unacceptable to me. And I
would extend that "to me" to anybody manipulating text (as opposed to
pictures) which was editing on a screen wider than the one they are
currently using. I readily acknowledge that wrapping isn't acceptable
if your intent is to edit a picture, table, etc. That EMACS doesn't
provide me with this does not concern me too much because I don't
do these things very often, although don't overlook how much the
capabilities of your editor may shape what you consider doing (like
if picture-making is easy, you may make more pictures!).
I only brought out the number of EMACS users to underscore that it is
not reasonable to expect the EMACS user community to accept throwing
EMACS away wholesale for the sake of a monitor hack. I think it's
rather bizzarre that this discussion started as a suggestion for how
to improve EMACS response by throwing away the EMACS command set as
being "too hard to do efficiently" or whatever.
Please don't try to paper over the fact that Steve *DID* attack EMACS.
I think the resulting barrage was completely justified. Unlike a lot of
high-intensity flaming, however, I think this has been a very
educational exchange on all sides.C70:editor-people (06/10/82)
>From LCAMPBELL@DEC-MARLBORO Thu Jun 10 02:18:04 1982
Remailed-date: 10 Jun 1982 0001-PDT
Remailed-from: J.Q. Johnson <Admin.JQJ at SU-SCORE>
Remailed-to: Editor People: ;
Regardless of the relative merits of EMACS vs. Z, if EMACS has
(for example only) 10,000 users and Z has 1,000, it makes a whole
lot of sense to add features to the monitor to speed up EMACS.
Computer manufacturers don't spend millions of dollars developing
COBOL systems and adding hairy packed-decimal instructions to their
machines because they like COBOL; they do it because there are
zillions of COBOL users out there.
--------