Newsgroups: comp.editors Path: utzoo!utgpu!cunews!bnrgate!scrumpy!bnrmtl@bnr.ca!lewis From: lewis@bnrmtl.bnr.ca (Pierre Lewis) Subject: One user's editor wish list Message-ID: <1991Feb22.134323.20410@scrumpy@.bnr.ca> Sender: news@scrumpy@.bnr.ca (USENET (SY)) Reply-To: bnrmtl!lewis@larry.mcrcim.mcgill.edu Organization: Bell-Northern Research Montreal, Canada. Date: Fri, 22 Feb 91 13:43:23 GMT I've come across and used quite a few different editors in my 15+ years in the business: starting with keypunches, edlin style editor on real TTYs (PDP-8), many full-screen editors (vi, SPF, XEDIT, PE2, Brief, Turbo C's, EVE, and other proprietary editors), and a few word-processor (WP5.0, Publisher). I find discussions on editors in general very interesting (comp.editors is one of the few newsgroups I regularly read). I've been wanting to organize my thoughts on the topic for a while and finally did it. Here's what came out -- hopefully will be of some interest, esp. to those who are developing editors. Of course it's one person's opinion, and it seems to be a minority opinion. ON VI But first a word on vi. Vi is not my favorite editor (-: stands for VeryIrritating, doesn't it? :-). But there is one VERY GOOD THING about it: it's universally available on all Unix systems (and then some) and works on practically any terminal. Because of this, anyone using Unix professionally should certainly be sufficiently familiar with this editor to do useful work. But for most of my work, I prefer something else! And I agree it's a powerful editor that anyone can get used to without too much work (at least for a minimum subset). But I think it is also lacking in some important features such as the ability to edit multiple files at the same time (and copy stuff between them). And personally, I don't like its user interface, esp. the modal functioning. The first time I came in contact with Unix and C was at an introductory course on above topics. We had the choice between vi and emacs and frankly I don't think either editor is very intuitive and will let one be comfortable in two or three days. For such a course, something simpler would be needed. Vi may well be the preferred editor of some people (and that's fine), but the number of requests in comp.editors for a simple editor on Unix indicates (I think) that vi is not the ideal solution. I haven't seen such a request for DOS yet, surely because there is no lack of good editors here including simple ones in this environment (e.g. even IE that came with my PS/2 is very simple and yet quite sufficient to edit CONFIG.SYS, etc). Maybe that some of my criticism about vi is unjustified and is due to my lack of knowing how to use it properly. THOUGHTS ON WHAT A USER INTERFACE SHOULD BE LIKE (AND HENCE EDITOR FUNCTIONS) The following summarizes what I think the interface and functions of a text editor should be like. A text editor is the tool a software developer spends a good portion of his/her time working with (for program development of course, but also for e-mail and simple documentation). Does not apply to a word processor. Of course it's my preference and there will never be one single editor for everybody. 1) Display should be WYSIWYG. This means (to me!): 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. For two reasons: - 1st, it can hide the indententation of a fragment of program. For example, the following bit of C code | if (gPcvcb->vcol + gPcvcb->rccol > gCurlgt - tlgt) | { | gCurlgt = gPcvcb->vcol + gPcvcb->rccol + tlgt; | if (gCurlgt > LSZ) | { | gCurlgt = -1; | return FALSE; | } | } becomes in a small window | if (gPcvcb->vcol + gPcvcb->rcc| |ol > gCurlgt - tlgt) | | { | | gCurlgt = gPcvcb->vcol + gPc| |vcb->rccol + tlgt; | | if (gCurlgt > LSZ) | | { | | gCurlgt = -1; | | return FALSE; | Structure is now harder to read, and (and two extra horizontal lines are needed so we see less of the structure). - 2nd, it often misleads writers into thinking their text is OK when in fact it isn't (I've seen that often in e-mail). For example, they see: 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. For two reasons: But their file is in fact... Strict window on file: just as it (unintentional long line 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. For two reasons: I just saw exactly such an example in a comp.editors article! One could detect this with careful observation of cursor behaviour, or by resizing the window. But otherwise it's not obvious. What the writer is going to get when he/she saves his/her work isn't what he/she sees. What I prefer is an editor that shows what it can of a given line and of course allows one to scroll right (and left) just as one can scroll down (and up). Optionally, it can signal long lines thru a special char (e.g. "!") at the end of the displayed portion of the line. With such an editor, if one unintentionally writes a long line, the editor will somehow (e.g. by scrolling horizontally) tell him. b) Editor automatically strips trailing blanks (they can't be seen so they should not exist). I remember one colleague wasting hours trying to understand why his few-line macro wouldn't work. #define etrace(msg) \ if(stdtrace) fprintf(stdtrace, "%s %d (%d): %s\n", \ __FILE__, __LINE__, (int)(time(0)%300L), msg) The reason, it turned out, was that his favorite editor left a trailing blank (which he, of course, had accidently typed) following one of the "\" with the result that it no longer meant continuation. I don't know of any application where trailing blanks are useful (and then there's always vi). Granted, an editor that strips trailing blanks can't edit some uuencoded files. But I've done that once in 3 years (with vi). c) Tabs are expanded, again because they're invisible. In addition tabs tend to be a nuisance since people attach different values to them and because they are sometimes used to compress file transmission (e.g. PROCOMM I think). But tabs are a necessity at least in makefiles and some way of keeping them is of course needed. When I look at tabs in source code (my editor shows them if I want to keep them), I invariably see inconsistant usage (some lines with, some without); what's the use? I prefer to use tabs for positioning (as in PE2 and XEDIT), not to insert data. d) Non-modal. The main reason is I can't tell from looking at the display what mode I'm in and I guess I have a poor memory (and, in vi, keep forgetting to hit ESC). WYS does not tell you what mode you're in. 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. If the cursor is in some position in my window on the file (say at the end of a long line) and I hit cursor down, I want the cursor to move DOWN, not SIDEWAYS! The fact that the next line is shorter shouldn't be an excuse. If I now enter a character at that position, it's up to the editor to extend the line (with blanks I guess). Note that this implies that trailing blanks are removed and that tabs are expanded. This way I can add asterisks on the right of a comment block simply by typing "* Down Left * Down Left * ..." instead of having to tab to it from the ragged ends of my text for each line. Another advantage of not moving sideways is that you can use the cursor to "remember" a column position as you scroll down or up. On the display, I like a status line and expect a command line. 2) Editing keys This is a controversial topic. Clearly WP5.0 style is far from ideal (too many combinations, impossible to remember). 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. I like to associate browse functions to keypad, editing ones to keyboard. And I don't mind moving my hand a few centimeters when switching modes. A definite plus however is for the editor to be able to function without a keypad (even if it's less convenient). 3) Essential features: - EASY TO LEARN and as INTUITIVE as possible. An editor that comes with 300 pages of documentation is NOT easy to learn. SMALL is beautiful also applies (i.e. you shouldn't need one meg to edit an hello-world program). - Basic features: insert/edit, intelligent split/join, search/replace, delete lines, yank lines and the like. Autoindenting of new lines. Support for non-printing characters (such as FFs, ESCs, TABs if kept) that may be in file. - Multiple (at least 2!) files simultaneously with of course possibility to move stuff from one to another. Typically organized in a ring. Should be able to name multiple files on command line, e.g. ed *.c. - Block operations (moving groups of lines for example). PE2's block operations are really good (blocks can be lines, streams, rectangles). - Undo or (at a minimum) recover facility. - 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). 4) Very useful features: - Multiple (at least 2) views simultaneously of same/different files. - 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). - Autosave or some other mechanism to prevent complete loss of a session on power failure. - 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). The reasons are - the meta-characters are not intuitive, - I usually know what I'm looking for (typically names), - the characters used in REs are also used in C programs with the result that the search is often not what I expected. Why not "s/string/" for simple search, "rs/string" for RE-search or something like that? - Right/left shift of groups of lines as when adding an if statement around a bit of code. - Marks (e.g. to quickly return to a given spot), direct line addressing. - Macros. Or 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. - Adjustable window size (for xterms). 5) Nice-to-have features: - Hex editing/viewing. The viewing is the more useful of the two. - 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). - Sort feature. First met this on CMS's XEDIT and find it very useful in all sorts of situations (not only for acronym lists). - Many people would name redefinable keys as a worthwhile feature. I find it's more of a nuisance than fixed definitions. It means that when you go help a colleague you're not going to be comfortable editing under his/her account because the keys now mean different things. You might even do damage under some conditions e.g. if one key that you use for something trivial causes the whole file to be reflowed. 6) Other observations - In general (but not for word processors), I prefer an editor that is line-oriented as opposed to character-oriented. E.g. in such an editor you can't join two lines by deleting the CR between them but you do it thru a special function key. Or you can yank a group of lines without having to be in the first column of the lines. The reason is that most programming I've done/seen is basically line-oriented. You move groups of lines around, not groups of characters. One counterexample: block operations in Turbo C are only character-oriented (stream). - 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. - 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. - Integrated environments (e.g. Turbo C, Saber-C). In all cases, I would like to have the choice of installing my own editor. Otherwise I am forced to learn yet another editor (and not typically one I'm comfortable with). On PCs, one editor stands out that is very close to above requirements. It's PE2 (discussed recently in this news group). And on CMS there is XEDIT which, given the unusual environment under which it works, is also very good. But on Unix (my usual environment), I didn't find anything that came close. So, rather than complain, I thought it would be fun to write my own, and this turned out to be a fascinating exercise. And the gain in productivity was well worth the effort (a few hundred hours for about 6 klocs). Of all the features I put in it that I don't find in vi, the most time-saving are paragraph reflow (for e-mail and doc) and multiple files. And the big advantage is that you can port your editor to whatever environment you work on (e.g. in my case a few Unixes and VAX/VMS). But I don't pretend or even think it could ever replace vi. For one thing, it's limited to vt100s (and emulations thereof such as xterm), and it's probably a bit too customized to to one specific user (although a few others actually use it). It's called "led" (as in Let's Edit Differently). -- Pierre LEWIS Internet: bnrmtl!lewis@Larry.McRCIM.McGill.EDU Alternate Internet: piotr@pmc.umontreal.ca (in case all else fails) P.S. - The ideas above are mine. My work does not involve writing editors (although that would surely be fascinating), but OSI. Brought to you by Super Global Mega Corp .com