root@ucbvax.UUCP (10/10/83)
From JQJ@SU-SCORE.ARPA Mon Oct 10 00:23:38 1983
Mr. Kerns:
Please acknowledge receipt of this letter to shivers@yale. I'm not sure if
I'm going to get your address right.
I read with interest your response to Michael Dyer's support of Z
over Emacs. I am a strong supporter of Z, but I think Michael missed
some of the essential differences of Z due to some unfamiliarity with
Emacs. I've never used Zmacs, but I used Zwei fairly extensively on
a Cadr at the MIT AI Lab, as well as the ITS Emacs for a summer, and
I suffered under Unix Emacs for longer. I know, for instance, that
one can rebind commands in Emacs, go into Picture Mode, and write
macros. I also know that cursor-motion was not an issue in avoiding
cursor-keys. I like mice.
But I still think that Emacs (or Zwei, or Zmacs) has serious,
fundamental problems that Z (or Win or Ice or U) has avoided. I also
think that Z is a bit misunderstood, because Emacs is everywhere,
whereas Z is at Yale. So I composed the following flame to hopefully
address that sort of thing. If it is successful in that task, I'd
appreciate your posting it to whatever bboard you distributed your
previous message to. Thank you.
-Olin Shivers
As an ex-Yalie, I shall join the fray and say where it is that Z
surpasses the emacs/Zwei/Zmacs editors. I'll get the heart of my
argument onto 1 page, for those of you who have a small attention
span for this kind of flamage.
Z wins over Emacs because (In descending order of importance):
- Z uses the quarter-plane model of a file, rather than the
stream model. (Except where the stream model is appropriate,
e.g. when you wish to delete a stream of text like a lisp defun)
- Z has a powerful, regular, flexible, clean argument facility,
as opposed to emacs' ad-hoc crufty old arguments.
- Z is fantastic for crowded systems. Much more efficient than
emacs. This of course means nothing to those of us with
personal machines.
Where does Z lose in comparison to Emacs?
- Not very extensible
- Doesn't handle bit-mapped screens, mice, personal machines, etc
- Doesn't know all that much about the syntax of the text you are
editing (Although it knows a bit)
Note Well: All of the lossage of Z is the due to the implementation,
NOT due to the style or "philosophy" it represents. The latest
incarnation of Z, as Dyer mentioned, is called U, and fixes them all,
while preserving all the features that make all us Yalies so
vociferously supportive.
Emacs is a very powerful editor. But it is OLD. Folks have built it
up in pieces over a long period of time. You pay a price for this:
inefficiency, and fragmentation. On a mainframe, emacs is a pig. Z
supports large numbers of users because:
- it is written in Bliss, which is more efficient than Teco
- it doesn't try to do the hairy things (the 98% philosophy)
- it made very clever use of the Tops-20 i/o characteristics.
Unless you work on a mainframe, these considerations are no longer so
important. (Of course, a lot of us DO work on a mainframe with 24x80
terminals, which makes that side of Z rather significant.)
More important than inefficiency in emacs is fragmentation. I don't
think it has a very unified approach to things, particularly in its
manner of handling arguments. This is due to its being built up
incrementally. In Z, most commands accept all of the below as
arguments with equal grace: -a box -a stream -a number -user entered
text -text on the screen or -a well chosen default. This makes the
operation orthogonal to the type of operand, one of the reasons
people keep saying how easy it is to learn Z.
The other great idea of Z is the quarter-plane model of a file.
Stream-based editors are infuriating in a myriad of small ways when
you become acustomed to the quarter-plane. As in when you want to
insert text in the "middle" of a tab. Note that Z allows you to do
stream-based operations, like delete all the text in a stream, so you
don't lose one functionality to gain another.
In essence, what makes Z such a win is that it was able to snarf all
the great ideas that Emacs demonstrated (modeless screen editors are
good), yet make a clean break from the old design for a fresher
approach. Z had the advantage of hindsight.
Now, there are those of you who prefer extensible editors, or editors
that know a great deal about the text they are editing. That is to
say, editors written in LISP. I agree. I think that an extensible
editor with the quarter-plane model and good argument handling would
be the best of both worlds. Hence I eagerly anticipate the final
tuning of U. Not Zmacs. Zmacs has all the featurefulness, but not the
right underlying design. Z has the right design, but lacks
extensibility. You can add extensibility, but you cannot "add"
something as fundamental as an "underlying design." That is why I
claim it is time to move on from Emacs, a great editor in its time.
So much for the overview. If you stay tuned for another page, I'll make
picayune technical points about Z.
Z is more portable than people think. Versions are written in Bliss,
C, and T (Scheme). The C version runs on the Berkely Unix and VMS
systems at Yale. I wrote this letter at CMU in it. Since it is
straight C rather than C and Mock-Lisp, it's a lot more efficient
than Unix Emacs.
T is supported for Vax Unix, VMS, and Apollo workstations. So U
should be pretty portable.
People who object to cursor keys can always rebind them to Emacs
bindings. A Unix fanatic at Yale had a VI-like command set for his
Z.
Stallman flamed on Z about a year ago (I think), claiming that an
editor that overwrote text instead of inserting text was "broken."
("Inserting" means the character I type is inserted in front of the
character the cursor is on; "overwriting" means the character
*replaces* the character the cursor is on. Just to get the
definitions straight) People have this misconception that Z is just
an overwriting editor. Look: there is this one-key command (^n).
It toggles the insert mode. You're told on the status line what mode
you are in. I usually work in insert mode, unless I shouldn't. It
is easy, and commonly done, to shift back and forth. No problem.
A common counter to us Z-types who bitch about Emacs is to say: Oh,
yes, Emacs does X for you. X can be "picture mode", or "overwriting
text", etc.. Well, yes, but... do you ever do it? No. Is it easy
to do? Usually not. The stream-type things that Z does are easy to
do, and commonly done. It's a one-key command to delete a stream
(^s). One key to toggle the insert mode. But - it's a pain to do
all the quarter-plane stuff in Emacs. Not really an integral part of
the system.
Finally, lest you think the phrase "98% editor" connotes a total wimp
of a program, note that the Bliss version (the best one) does all the
following:
- fill and justify text
- paren or bracket balance Lisp, Bliss, Scribe, C, et al
- compile your program in the background, saving the error
messages. When the compile is done, a one-key command takes
the next error message, displays it in the message window, and
moves the cursor to the location of the error in your file.
Very nice. (.mss files compiled by Scribe)
- A great Session Manager. Run processes in a window, stuff text
to them.
- Two-key command takes you to the location of the next
misspelled word in your file. You can correct it, let the
computer try to, or insert the word in the dictionary.
- Interactive help facility.
- I'm very sure it's free to any University with a Dec20 to run
it on. (Same for the C version) I promise nothing; ask
Odonnell@yale.
Well, flame off. If you made it this far, you are a true stoic. I
generally despise the kind of frothing at the mouth that editor
discussions provoke, but this has been building up for a while. Z is
to editors as LISP is to programming languages: the One True Way.
-Olin Shiversroot@ucbvax.UUCP (10/10/83)
>From JQJ@SU-SCORE.ARPA Mon Oct 10 00:58:31 1983
Date: 22 Sep 1983 20:50:19-EDT
From: Olin.Shivers@CMU-CS-G
I've never used Zmacs,
but I used Zwei fairly extensively on a Cadr at the MIT AI Lab,
Actually, Zwei is the name for the underlying editor primitives that
support the text editor, Zmacs. So you have used Zmacs. The
boundary is not very clear, but editor primitives that are used in
other programs, such as ZMail, are part of Zwei, while things that
deal with buffers and files are part of ZMacs.
But I still think that Emacs (or Zwei, or Zmacs) has
serious, fundamental problems that Z (or Win or Ice
or U) has avoided. I also think that Z is a bit
misunderstood, because Emacs is everywhere, whereas Z
is at Yale.
This is certainly true. I was fortunate enough to get a demo of Z a
while back. Not many have.
Z wins over Emacs because (In descending order of importance):
- Z uses the quarter-plane model of a file, rather
than the stream model. (Except where the stream model
is appropriate, e.g. when you wish to delete a stream
of text like a lisp defun)
As I keep reiterating, there is nothing wrong with this model. But
it is not a panacea, nor is it the only one, by far. Z relies too
much on it, just as ZMacs relies too much on the stream models.
- Z has a powerful, regular, flexible, clean argument
facility, as opposed to emacs' ad-hoc crufty old
arguments.
What? Holding down the meta-key and typing a number is ad hoc? I
think you miss the real criticism. The MEANING of these arguments is
often ad-hoc. Many commands take an argument to mean "do something
slightly different". This wouldn't be so bad if there were more
uniformity as to what "slightly different" means. Often it means "do
additional prompting", which is fine. Usually one uses c-U to supply
the argument in this case, although generally you could type a
specific number. On things where a repeat count makes sense, it
means that. Generaly one gives a specific number, or c-U to mean x4.
I.e. c-U c-U c-U means "A whole lot" (4x4x4).
This is pretty consistant, and not very crufty. Where cruftyness
comes in is that not everything follows this convention. Where Z
does it better is that you can give arguments in terms of distances
on the screen. Although I think that this implies a kind of mode
that is a bit crufty.
On a mainframe, emacs is a pig. Z supports large
numbers of users because:
- it is written in Bliss, which is more efficient than Teco
Bliss is more efficent in TIME, but LESS efficient in SPACE. Does Z
use extended addressing on the -20?
- it doesn't try to do the hairy things (the 98% philosophy)
I find EMACS too primitive. It's about 70% of a Zmacs.
Unless you work on a mainframe, these considerations
are no longer so important. (Of course, a lot of us
DO work on a mainframe with 24x80 terminals, which
makes that side of Z rather significant.)
With 24x80 terminals? Really? My god, I haven't touched one of
those in a very long time. There are good 60-line terminals out
there for reasonable prices.
More important than inefficiency in emacs is
fragmentation. I don't think it has a very unified
approach to things, particularly in its manner of
handling arguments. This is due to its being built
up incrementally. In Z, most commands accept all of
the below as arguments with equal grace: -a box -a
stream -a number -user entered text -text on the
screen or -a well chosen default. This makes the
operation orthogonal to the type of operand, one of
the reasons people keep saying how easy it is to
learn Z.
And I agree with this.
The other great idea of Z is the quarter-plane model
of a file. Stream-based editors are infuriating in a
myriad of small ways when you become acustomed to the
quarter-plane. As in when you want to insert text in
the "middle" of a tab.
Actually, this is due to the "wide character" model of a TAB; quite
separate from considerations of stream vs plane.
I wouldn't write off the Emacs family as dead. I see no reason why
we can't learn from the Z model and produce a synthesis. I see no
reason to give up the very convenient command layout for the most
common commands, the wide range of commands available in Zmacs, etc,
by simply adding on yet another model. I think that over the last
few years the argument syntax in Zmacs has tended to get cleaner, not
more messy, as conventions have been developed, and things are
changed to take them into consideration.
Z is more portable than people think. Versions are
written in Bliss, C, and T (Scheme). The C version
runs on the Berkely Unix and VMS systems at Yale. I
wrote this letter at CMU in it. Since it is straight
C rather than C and Mock-Lisp, it's a lot more
efficient than Unix Emacs.
It used to be considerably less portable, I understand. I'm glad to see
that this has been fixed.
Stallman flamed on Z about a year ago (I think),
claiming that an editor that overwrote text instead
of inserting text was "broken." ...
Look: there is this one-key command (^n).
It toggles the insert mode. You're told on the
status line what mode you are in. I usually work in
insert mode, unless I shouldn't. It is easy, and
commonly done, to shift back and forth. No problem.
As RMS said, "broken". This is what modelessness is all about. Why
should I have to look at my screen to know what mode I'm in? I think
this is the central issue, where Z and Emacs differ. And I think
EMACS is right. As you admit, usually you work in Insert mode.
INSERT IS INHERENTLY A STREAM OPERATION. Various studies have been
done as to the distribution of kinds of commands in an editor, and
they don't always agree. But I think all will agree that insertion
of characters is always one of the more common operations. You have
a mode where one of the most common operations is disabled! I think
that is a very serious flaw.
A common counter to us Z-types who bitch about Emacs
is to say: Oh, yes, Emacs does X for you. X can be
"picture mode", or "overwriting text", etc.. Well,
yes, but... do you ever do it? No. Is it easy to
do? Usually not.
m-X Run$Picture<return> isn't easy enough for you?
The stream-type things that Z does are easy to do,
and commonly done. It's a one-key command to delete
a stream (^s). One key to toggle the insert mode.
But - it's a pain to do all the quarter-plane stuff
in Emacs. Not really an integral part of the system.
This is true. I think the strength of Z lies in that the
quarter-plane model is always available when you want it. I have
some ideas for how to merge in the quarter-plane model in Zmacs that
I think are cleaner than Z's handling, given the mouse and bit-mapped
graphics.
Z is to editors as LISP is to
programming languages: the One True Way.
I think of Z as being to editors as Scheme is to Lisp. I.e. an
interesting diversion from the main-stream that we should absorb the
best ideas from.
Both T and Z have been able to explore a lot of good ideas by
abandoning any idea of compatibility. However, I think Joel Moses's
description of Lisp applies to to Emacs as well: a ball of mud; you
can add on more and more, and you still have a ball of mud.
A lot of good ideas have come along, and have been added. Thus Lisp
has advanced from very primitive beginnings to become the most
powerful software environment around, in the form of ZetaLisp. I
think the same adaptability is true in the case of the Emacs family.
It will undergo numerous purges, clean-ups, and adaption of new ideas
from outside sources.