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
-------