Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ucbvax.UUCP Path: utzoo!linus!decvax!harpo!eagle!mhuxi!houxm!ihnp4!cbosgd!ucbvax!root From: root@ucbvax.UUCP Newsgroups: fa.editor-p Subject: Emacs vs. Z in 24 lines (sort of) Message-ID: <93@ucbvax.UUCP> Date: Mon, 10-Oct-83 03:58:54 EDT Article-I.D.: ucbvax.93 Posted: Mon Oct 10 03:58:54 1983 Date-Received: Fri, 14-Oct-83 21:23:53 EDT Sender: root@ucbvax.UUCP Organization: U. C. Berkeley Computer Science Lines: 174 >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 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.