🚀 go-pugleaf

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