Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!agate!ucbvax!pasteur!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.editors Subject: Re: One user's editor wish list Message-ID: <11032@dog.ee.lbl.gov> Date: 17 Mar 91 20:41:39 GMT References: <1991Feb22.134323.20410@scrumpy@.bnr.ca> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 331 X-Local-Date: Sun, 17 Mar 91 12:41:40 PST [Note, there is an important observation at the end.] In article <1991Feb22.134323.20410@scrumpy@.bnr.ca> bnrmtl!lewis@larry.mcrcim.mcgill.edu writes: > a) Strict window on file: just as it is in general not possible to see all > lines of a file, I also don't need to see all columns. I don't like > editors that wrap lines. GNU and Unipress Emacs (and others) have this as an option; vi does not. > b) Editor automatically strips trailing blanks (they can't be seen so they > should not exist). Easy to program in Emacs, somewhat uglier in vi. The magic vi command is :%s/[ ][ ]*$// (substitute on space-or-tab followed by zero or more space-or-tabs followed by end of line; replace with nothing). This can be mapped to a key sequence (including `ZZ'). This depends on the `magic' setting. > c) Tabs are expanded, again because they're invisible. This issue is a complete morass. There are many `kinds' of tabs: ASCII code 9, in files. What the terminal (or window or whatever) does with the above. What TAB key on the keyboard sends. What the editor does with the sequence the TAB key sends. No matter what you do with the ones you can set, someone will be unhappy. To be consistent, however, you must: 1. rule that ASCII 9 in files means `move to (col-1)%8+9'. [Note: columns here are numbered from 1 at the left, and `%' means `mod'.] 2. use the termcap/terminfo description to figure out what hte terminal does and accomodate it. You can then map user `tab' key sequences into anything you like. If, however, you map it to anything other than `insert one ASCII 9', you must make more decisions, about which someone will be upset. GNU and Unipress Emacs allow you to program whatever you like. For instance, in `picture mode' the cursor can go anywhere and appropriate whitespace will magically be created as necessary. Unfortunately, the magic whitespace is either: - all spaces: some people will complain, others will be happy; - minimal combination of spaces and tabs: same, but the two groups are reversed. Also, the magic whitespace (choose any or all of the following): - causes existing whitespace to be remapped to minimal whitespace; - leaves existing whitespace alone; - automatically removes inserted magic whitespace; - always leaves inserted magic whitespace behind; - removes magic whitespace conditionally; - ; and no matter which you choose, someone will claim it is wrong. vi does not (quite) let you program a picture mode since you cannot tell whether | will move to the given column, or will land on a tab and move to column number (-1)%8+8. > d) Non-modal. Ill defined; `mode' means too many different things. In any case, Emacsen generally allow you to be nonmodal without requiring it, but make it hard to be `modal' in the style of vi and encourage you to have `file modes' (tab does different things when editing .el files vs .c files, e.g.). Since Emacsen are generally programmable, you can do anything you want here. > In addition, another thing I want (and which frustrates me no end on vi) > is total freedom of movement in the window and automatic scrolling when > cursor hits a border. Can be done in most Emacsen. > On the display, I like a status line and expect a command line. Can be done in most Emacsen, although the `status line' may require a blank line above it (though you could use that for your `command line') and may always be highlighted. >2) Editing keys > > This is a controversial topic. No kidding. :-) > What I prefer (although I recognize it limits range of terminals) is > keypad for general positioning (page down/up, next file, insert/replace > mode) and c-keys (or alt keys on a PC) for editing (c-y for yank, c-r for > repeat line, c-x for delete &c). Use of a keypad is typical of VAX/VMS > editors (EDT, EVE) for example. I see two user modes when using an editor, > browse mode (looking for stuff) and edit mode. (You just said you did not like modes. See what I mean about `modal' having different meanings? Here it means `the user's brain mode' and not `the editor's key-action mode'.) In any case, both vi and Emacsen can do this, provided you are willing to `limit [your] range of terminals'. vi has more trouble since it tends to be in `insert mode' or `edit mode' (you have to make heavy use of map and map!, and some mappings are impossible---more on that in a later article). >3) Essential features: > > - EASY TO LEARN and as INTUITIVE as possible. `Intuitive' is undefined. Intuitive to Joe may be gobbledygook to Jane, and vice versa. >An editor that comes with 300 pages of documentation is NOT easy to learn. This is the price of extreme flexibility (Emacs). It is, however, not necessary (and is often undesirable) to give everyone the complete documentation. People who are frightened by documentation length may be given a `dumbed down' configuration and manual. >SMALL is beautiful also applies (i.e. you shouldn't need one meg to edit >an hello-world program). Well, that lets GNU Emacs out :-) . > - Basic features: insert/edit, Modes again! >intelligent split/join, vi has the latter, Emacsen can do both. >search/replace, (he means `without regular expressions' here:) Emacs has this, vi requires `set nomagic'. >delete lines, yank lines and the like. Everything has this. >Autoindenting of new lines. vi has this in limited form (`autoindent', `shiftwidth', and ^T/^D); Emacsen of course can do anything here. > Support for non-printing characters (such as FFs, ESCs, TABs if kept) > that may be in file. Unclear: `support' as in `leave them there but do not show them', or as in `allow them to be added/removed', or `show them in inverse video', or `show them in control notation ^K', or...? There is an almost infinite variety of ways to handle this. vi gives you one; Emacsen generally give you two. > - Multiple (at least 2!) files simultaneously with of course possibility > to move stuff from one to another. vi can do this, albeit painfully. Easy in most Emacsen. >Typically organized in a ring. The files are in a ring? (makes no sense.) > Should be able to name multiple files on command line, e.g. ed *.c. Everything does this. > - Block operations (moving groups of lines for example). PE2's block > operations are really good (blocks can be lines, streams, rectangles). vi has this in somewhat limited form (blocks are `sentences/paragraphs/ marked lines/marked streams'); Emacsen can do anything (including rectangles: see picture mode). > - Undo or (at a minimum) recover facility. vi has this in somewhat broken form (U is line undo, breaks if you move off the line; little-u undo fails after complicated macros). Emacsen have undo. Both can recover, if by this you mean `bring the file back in' (:e! in vi, read-file in Emacsen). > - Protection against destructive writes. For example, vi allows the > following: user1 and user2 are both editing the same file. User1 > saves his work and then user2 saves his work thereby destroying > user1's work (this latter save should be refused because the file is > no longer the same as when it was read in). A few vi variants have this, most Emacsen do. >4) Very useful features: > > - Multiple (at least 2) views simultaneously of same/different files. vi had this, then Bill Joy lost all his work when the disk crashed, because the backup device was broken (this back in 197x). Since then no one has done it again. vi's internal structure (or lack thereof) makes it very difficult. Emacsen of course have it. > - Access to system (shell) without quitting editor. In particular, > possibility to pipe the output of a command into the editor (in a new > "file", e.g. >diff - orig.file). Or even both together, to filter a file. Maybe > this belongs in the previous section (at least in part). Every sane Unix editor has this (vi and all Emacsen included). > - Autosave or some other mechanism to prevent complete loss of a session > on power failure. vi has `vi -r', Emacsen generally checkpoint. > - RE searching: at the risk of shocking a lot of readers, I'll say that I > don't find this very useful (except in ed scripts and the like). Most programmers will never give them up. vi has magic/nomagic (kludgy since it cannot be saved & restored in macros); most Emacsen have plain and `regular expression' operations as separate entities, and you are free to use either or both (I use both, with `plain search' as my default, in my own private version of Emacs). > - Right/left shift of groups of lines as when adding an if statement around > a bit of code. vi and Emacsen have this. > - Marks (e.g. to quickly return to a given spot), direct line addressing. vi and Emacsen have this. > - Macros. Or learn mode. vi and Emacsen have macros (in vi, macros are the only extension mechanism); Emacsen have learn mode. > - A minimum of WP features: word wrap and paragraph reflow are very > useful (as in PE2), particularly for e-mail. I'd even add spell > checking to the nice-to-have features. Emacsen have this. vi allows piping through external programs to do it; the `fmt' program (comes with BSD, available elsewhere) does the `reflow'. > - Adjustable window size (for xterms). Emacsen have this. Some versions of vi have this, with concomitant bugs. Having put this into my own private Emacs, I will attest that it is very difficult to do this right. >5) Nice-to-have features: > > - Hex editing/viewing. The viewing is the more useful of the two. Not sure exactly what this means, but since Emacsen and vi have filter capabilities, you can always turn the file into hex, edit/view, then turn it back into regular data. > - Line exclusion (possibility to exclude a group of lines from being > displayed - useful to better see a complex structure, e.g. by hiding > uninteresting code that clutters a switch statement). vi cannot do this, and many Emacsen (including mine) cannot. I believe GNU Emacs can. > - Sort feature. First met this on CMS's XEDIT and find it very useful > in all sorts of situations (not only for acronym lists). Just sort the file (use the filter capability if you prefer). > - Many people would name redefinable keys as a worthwhile feature. I > find it's more of a nuisance than fixed definitions. If they are not redefinable, it is impossible to use keypads, because every keypad has a different setup. >6) Other observations > > - In general (but not for word processors), I prefer an editor that is > line-oriented as opposed to character-oriented. vi does both, for just about everything. Emacsen do characters but it is easy to program them to select whole lines as their character ranges. > - I don't personally like an editor that jumps around to show me () > matching and the like. If it's available, I want to be able to turn it > off. I tend to write the two together and then insert within. vi and Emacsen all have options. > - Guess-typing by the editor (I seem to have heard of that at one point) > would drive me insane because it would force me to continuously control > what's going on. I have no idea what this means. And last, the important observation: Although most Emacsen can be programmed to do anything you want, it generally turns out that those who are willing to learn what it takes to do this are not the ones that want to reconfigure the editor. (There are some notable exceptions.) The trick is that a dumbed-down Emacs (wired to `editing policy X') can be written, but to do it you have to learn how, and by that time there is no longer any reason to do it. Thus, to get a dumbed-down version for N people, at least one person must first learn how to really use the editor. At that point the one person generally no longer wants to create and document the dumbed-down version: she would rather teach the others how to use it (`because all this stuff is so *useful*'!). The only way to bootstrap, in other words, is to commit someone to it as a special project. Universities generally do not have the resources to spare, and corporations generally have the money to just buy something else. Hence there are few, if any, programs for Emacsen that wire them into some particular editing policy. There are plenty that `almost work', written as an exercise, but they are usually not good enough to be used by those people who complain about Emacsen being `too complicated'. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov