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!security!genrad!decvax!tektronix!uw-beaver!cornell!vax135!floyd!clyde!ihnp4!houxm!mhuxi!cbosgd!ucbvax!daemon From: daemon@ucbvax.UUCP Newsgroups: fa.editor-p Subject: Message-ID: <904@ucbvax.UUCP> Date: Wed, 21-Sep-83 03:51:22 EDT Article-I.D.: ucbvax.904 Posted: Wed Sep 21 03:51:22 1983 Date-Received: Fri, 23-Sep-83 03:01:44 EDT Sender: daemon@ucbvax.UUCP Organization: U. C. Berkeley Computer Science Lines: 295 From JQJ@SU-SCORE.ARPA Wed Sep 21 00:50:54 1983 Date: Tuesday, 6 September 1983, 08:28-EDT From: Robert W. Kerns Subject: Learning Z vs Zmacs To: Dyer@YALE, editor-people@SU-SCORE Thank you for your well-thought-out message. I have some comments on your message. A lot of the things you thought you couldn't do with Zmacs, you really could, if you'd known. Indeed, I learned a lot just from looking at what you didn't know about Zmacs. I don't mean this to be a defense of Zmacs, although a lot of verbiage goes into explaining that yes, you can do X in Zmacs. But I think there's something to be learned from contrasting how the two do things. I don't think Z's solutions are adaquate for Zmacs in many cases, but I think they often point to areas that Zmacs could use some work. Date: Sun, 31 Jul 83 16:25:23 EDT From: Michael Dyer Z is a window-editor designed by Steve Wood and augmented by the tools-group at Yale. Here are a few reasons I prefer Z over both e/zmacs and VI. 1. It's EXTREMELY easy to change command key assignments. A simple command does this. This is true of both Emacs and Zmacs. m-X Set Key. Or the user can change a command entry in a file which Z accesses for keyboard interpretation. Or the ZWEI:SET-COMTAB function in your init file. At any time you can type a command which will display all your current personal keyboard assignments. A fine idea. 2. Z is a picture-based window editor. This means that, unlike stream-based window editors, in Z "what you see is what you get". In stream-based editors, such as emacs, you can't simply move the cursor to any empty part of the screen, since, as its designers will tell you, "you can't go somewhere where there isn't anything". It depends on what you're editing whether or not this is the right thing. Emacs has a Picture Mode. Nobody has yet bothered to do this for Zmacs. Indeed, there are many advantages to a picture-editor for ease of learning. However, there are definite problems with such things as literal strings in programs, etc. In Zmacs, of course, it should take advantage of the mouse, to DRAW a rectangle. 3. Z is intelligent about what mode it is in. A simple command can switch you in and out of insert mode and you can make either your primary mode. But Z also tries to pick the best mode for you automatically. For example, if you issue the delete-word command, then Z enters insert-mode (if you aren't lready there) so that anything you type will end up replacing the word just deleted. However, if you issue any other command, or move the cursor, then Z automatically exits insert mode. Z is 'modeless' in the sense that any command works whether in insert mode or not. Hmm. I don't understand this one. It sounds like it doesn't have two modes at all. Can you explain? 4. The philosophy of Z creates an editor that can be learned in a few minutes. I have seen novice users become FLUENT users in about 20 minutes! In a non-stream editor a minimum of commands are needed to do most editing operations. In Z, the default command design, organization and layout is quite good. Every command, such as pick, put, etc. is generalizable in a systematic way. I'll just point out that Emacs and Zmacs have their own systematic generalizations, and that this is the basic technique for handling complexities in keystroke-based editors. However, these generalizations break down when you break out of the domain over which they are effective. For example, Zmacs has commands for moving over things. There's characters (c-F = forward , c-B = backwards), "words" (m-F, m-B), and "expressions" (c-m-F, c-m-B). The meaning of words and expressions depend on the language being edited. This same pattern holds for commands that delete things. Note that this is stream oriented. Many things are. Running text is one stream-oriented kind of thing to be edited. You would be hard-pressed to delete a lisp expression with a box command, just as you would be hard-pressed to delete a rectangle in a table with stream commands. The central tenet of my philosophy of editors is that every editor must be prepared to deal with a multiplicity of models and representations. Z deals with some that Zmacs does not, and I have regretted it from time to time. But not enough so to spend a few days playing with some Z-like extensions, I guess. Still, I hope someone does. 5. Z is also designed to minimize the number of keystrokes needed to accomplish anything. For example, I remember the incremental search feature that Norman referred to in emacs and zmacs. However, often I wanted to search for another occurrence of a string elsewhere in the file that ALREADY APPEARS on the current screen. In Zmacs, you have to still type in the string to search for. But in Z you simply move the cursor to that string, hit the command, followed by the search command, and you'll be searching for the next occurrence of that string. Likewise, suppose you want to go to a file, say "foo.lisp", and the string "foo.lisp" happens to be a string in the current file. Then, in Z, one simply puts the cursor at the left of that string and hits the go-to-file command. ... You can also edit the argument you give after c-X if you made a typo. In general, I found that zmacs makes me do a lot more typing than Z. It was very frustrating to have to type stuff to the editor-command-interpreter when what I was typing was ALREADY available as a string on the screen in front of me! Ah, but you can do this in Zmacs too! c-X c-F, and when it prompts for the filename, mark it with the mouse, do Shift-Mouse-Middle to collect that, and c-Y brings it into the minibuffer. You can then edit it as much as you like. (In fact, if you find what you wanted doesn't happen to be on the screen, you can use mouse-scrolling to go find it, and THEN pick it up). Admittedly this is incompatible with incremental search, but this is hardly incremental. Use the non-incremental search on Control-Shift-S instead. Why didn't you know about this? Several reasons. The principal one is that it isn't documented as a technique, although you can deduce it from the line documenting the mouse commands at the bottom of the screen. Secondly, it's not a pervasive enough technique to be in the set of things a typical user learns. This is one of the pitfalls of having a large incrementally-designed system. It really doesn't play a large role in the command philosophy, and so is relagated to the status of an obscure trick, rather than the reasonable technique it really is. In fact, I never use it, because remembering it is harder than typing for me (which I do very quickly). 6. One reason it is easy to learn Z is that local movement within one screen is done by simply using the cursor arrows. This is one reason Z is easy for novices to learn. I've been told that this approach did not develop at MIT because their terminals have very slow cursor movement. Too bad. No, it's *NOT* because the terminals have slow cursor movement. Bit-mapped screens and VT52s do not have that particular problem. It's because it SLOWS DOWN THE USER to have to move his hands to the arrow keys. I found it a pain having to memorize zillions of commands just to move around on the screen. (e.g. a different command for forward/backward char, word, line, paragraph, etc.) {f=Forward, b=Backward} X {Control=Character, Meta=Word, Control-Meta=expression} c-N=Next line, c-P=Previous line. This isn't so bad, which is a good start, no harder than Z's own pattern of commands with c-F and c-D. But it doesn't extend to a uniform scheme of naming other kinds of objects. Lines? Paragraphs? These have keys of their own, semi-mnemonically chosen, which I use. But there is also c-Q c-Q takes two characters following. The first is an operation (Forward, Kill, Twiddle (exchange), etc.) The second is the nature of what you want to move forward over, kill, or whatever. (Character, World, Paragraph, Page, etc.) Unfortunately, this is marred by the fact that c-Q is also used for quoting. If the character following is not a letter or digit, it is inserted literally. Sigh. What drives a beginner crazy in zmacs is that you have to move the mouse AND THEN click a mouse button to move the cursor. Beginners commonly move the mouse and then start writing, only to find the text being inserted where the cursor (still) is, rather than where they intended. For those who want to learn forward/backward movement by word, sentence, etc., Z has them. If the mouse is used to say where to insert characters, you lose the ability to use it for anything else, such as choosing between windows, menues, etc. While it might seem obvious to the new user that the mouse cursor is where characters are inserted, it would be a very bad interface in practice. Mice move. Mine usually sits on top of my manual. Should I lose my place every time I look something up? Or when someone bumps into my desk? 7. Many systems claim session management, but many of them are missing useful portions. Z has session management with the ability to "stuff" text from one environment to the command interpreter of another environment. E.g. Suppose I want to know how many words my natural language parser currently handles. In lisp I type "(setq STORIES " I jump to a file of current stories handled by my parser. I put '( ) around these stories. I pick up the stories and stuff them back to lisp, close off the setq command and now STORIES is bound. I run (SORT (REMOVE-DUPLICATES STORIES)). I use the editor copy command to pick up the result and put it back into another file. I now have a nicely sorted lexicon. Thus, I jump in and out of the lisp and editor environments at will. It's very convenient and beats the piping alternatives unix hackers must use. It's also vastely superior to the ztop, zwei and dribble modes of Zmacs. Symbolic's "answer" to session management was to build a silly command-line editor. So, on the Symbolics, you can edit the last few commands you typed, but you CAN'T take any of the text the system displayed back at you and pick it up to use it informulating a new command. One should be able to jump around, get text from anything displayable on one's screen and use that text as a command for whatever processor one is currently executing. Actually, this "silly command-line editor" is not our "answer" to anything. It is just an interim measure until we integrate it all with ZWEI (the editor base beneath ZMACS and everything else editor-like). I believe parts of this will be done soon; we'll see. 8. Z knows about the basic syntax of a number of languages, including LISP and SCRIBE. So Z can balance parentheses and act like a structure editor. It also can do the usual limited formatting stuff, such as filling and justifying text, (and you can use the box-feature to specify what shape the justified or filled text should take), centering, upper/lower-casing, etc. Z also has a soft-carriage-return feature. I.e. Z tries to put the cursor below the correct s-expression. This soft-cr feature is sensitive to the language you're using (determined by the file extension). This is, of course, a feature of Emacs and Zmacs as well. 9. Z has great help facilities. You can give it either a term or a keystroke and Z will jump to a short file of documentation about that Z function. Upon request, Z will tell you your complete, personal keyboard layout. Since all help information actually resides in files, you can edit them and quickly make your own summary-document copy of your favorite editor commands. (The Symbolics displays zmacs editor documentation on the screen, but the user cannot "grab" it for re-formatting.) Well, actually you can do this too. Again, it's awkward. m-X Execute Command Into Buffer followed by whatever help command you want. Hopefully when the editor command documentation is built on our new documentation system, we will learn something from Z and make it easy to edit what you just saw. 10. Z has convenient user-accessible switches to specify the size of a window, screen wrap around, whether to ignore uppercase during searching, how many keystrokes before autosave of a backup file, etc. Z also has a regular-expression notation that can be used in the for searching. Similarly with Zmacs. You can do insert-puts or clobber-puts at will, no matter which mode you're in. It's got book marks for scoping commands, etc. But the key assignments are systematic enough that all this can be memorized in a few days of use. I find it incredible when people say it takes them a few MONTHS to get expert on an editor! There are 207 long-named commands that you can get with m-X in Zmacs. I don't know them all, and I've been using Zmacs for years. There are two factors in how long it takes to become an expert in something. Only one is how difficult it is. The other is the scope covered. Zmacs could use some work to render the command set more consistant, it is true. But you won't cut down on the commands by much. Not when you have such a large set of things being dealt with that are not handled by Z. There are twelve commands dealing with fonts, for example, and I would term our current font support as primitive. There are 25 commands for operating on function definitions in the current language. (These include editing or compiling all those which have changed, or making those which have changed into a patch file.) The list is very, very long. So becoming an "expert" can take a very long time, because we consider an expert to be someone who uses the totality of an editor very effectively. But as for proficiency in straight text-editing, I don't think the disparity is nearly so large. (I can't give an unbiased opinion on which is easier to learn). 10. Emacs people will say "but emacs is extensible". Good point. I've heard, however, that to extend emacs you have to learn TECO. To extend Z you can write macros by specifying series of Z commands. You can do this in Emacs, too, but I wouldn't call that true extensibility. True extensibility requires being able to write a program, with data structures, predicates, conditionals, loops, etc. True, Teco is not an easy extension language to learn. And the Zwei primitives on which Zmacs is based are not yet documented. (Of course, you do get the source for Zmacs with your system, so you can learn by example, if you're determined). Hopefully we will be rectifying this soon. But now there's U, a Z-like editor written in T. (T is a highly efficient, compilable scheme-like lisp, with lexical scoping and closures.) People who refuse to touch any language other than lisp can add new editor commands to U on their own. This may not be needed, however, since U apparently has a "learn from example" feature. The designer of U is Bob Nix. This is very interesting news. It seems that Lisp is now far-and-away the most-used editor extension language, with editors written in ZetaLisp, MacLisp, NIL, Common Lisp, and T. (That covers most MacLisp dialects, does anybody know anything about text editing in InterLisp?) I would be interested in hearing more about U.