From: utzoo!decvax!ucbvax!C70:editor-people
Newsgroups: fa.editor-p
Title: The Recent Roast
Article-I.D.: ucb.1199
Posted: Thu May 27 06:39:35 1982
Received: Sun May 30 00:46:33 1982

>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
-------