From: utzoo!decvax!ucbvax!C70:editor-people Newsgroups: fa.editor-p Title: Editor Flame Article-I.D.: ucb.1180 Posted: Tue May 25 21:12:39 1982 Received: Sat May 29 03:12:56 1982 >From LAWS@SRI-AI Tue May 25 19:33:54 1982 I am not surprised that authors of successful editing systems each prefer their own. As a user, I see merits on both sides and would like to see both systems flourish. My own preferences on particular features are noted below. Since they are just preferences, it would seem reasonable that other options be available in the same editor or at least in other editors on the same operating system. * I like the character string model of a text file for editing raw data from tapes and for converting one character set to another. Unix is built around stream I/O, and it works very well. The "stream editor" is particularly handy for processing large text files in some uniform way. I prefer the quarter-plane model for document editing. One place it wins is in moving blocks (not full lines) of text around. Top-level replace mode is best with this model. (My experience here is with the Rand editor NED.) For special purposes I prefer a special editor or mode. A LISP editor is essential for LISP coding, and VisiCalc is excellent for worksheet computations. For graphic arts or newspaper layout I would want a formatting editor as in XED or Smalltalk. * I like an editor that understands my problems and gives me tools (and a language) for dealing with them. For general text processing I like the built-in primitives of VI (character, word, "metaword", line, sentence, paragraph, section, and matching parenthesis or bracket). Vanilla EMACS is less knowledgeable but more flexible, particularly in the LISP-based versions: I would prefer it if I were building a bibliography editor or other special-purpose system. Even with a smart editor that understands my text I would like a good cursor system. The vanilla EMACS bindings of ^F, ^B, ^P, and ^N are exceedingly awkward, and the VI bindings of h, j, k, and l are not much better. Sometimes I just want to get from here to there, and many editors make this difficult. A good cursor system is even more important when the editor does not understand the text. As an example: Most of my work is done with word motion and word-oriented commands. In my programming work, however, I must deal with variable names such as newimghdr or ImageColumnsPerBlockRow. I have yet to find an editor that can tab into these composite words intelligently, so I must rely on cursor motion no matter how clumsy. (With a mouse, of course, I might prefer cursor motion to all other systems.) Given that keyboard cursor control is necessary, I think it integrates best with the quarter-plane model and top-level replace mode. I should also be able to move the cursor between editor windows -- other commands should be used to control text scrolling within a window when more than one window is present. * I also want to have available a marker system. EMACS offers only one marker other than the cursor position, and its use is stream- oriented. NED's marker pair is "block-oriented". SOS offers multiple line markers (as well as line number addressing). VI has (invisible) line numbers and multiple markers with both stream-oriented and line-oriented commands. (VI needs them to offset the lack of multiple editing windows.) Why can't one system give me all of the above? * As for conversion of tabs to spaces (or vice versa): This certainly should not be mandatory (and no one has suggested that it should be). For text processing I usually prefer spaces -- adding one character to a word should not make the next word jump seven spaces. For tabular work I might prefer tabs. For programming I ordinarily want things left as they are. Just don't make NED's mistake: conversion of tabs to spaces only on lines that are actually edited. Sorry if this sparks a religous war. My thesis is that an editor should offer every conceivable primitive capability (hard-wired or via extensibility) and that the user should be able to have any subset easily available. If only subsets can be implemented then the choice must be made intuitively, or through controlled studies, or through user surveys. I have cast my votes above. -- Ken Laws -------