[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Sep 6 07:51:24 1993 
Subject:How to end silly editor wars 
From:"A.Sloman" 
Volume-ID:930906.05 

People who want to see editor wars can read (or contribute to) the
comp.editors newsgroup, which often includes people giving vent to their
personal prejudices without bothering to read the relevant human factors
literature.

VED and emacs were designed with quite different goals. As one of the
early designers of VED I can say authoritatively that a major goal was
to make it relatively easy to learn by relatively non-computerate people
(e.g. secretaries, arts undergraduates) who had access to certain
standard VDUs, in particular VT52 and VT100 terminals. In this it was,
at the time, pretty successful: and even now it is used by secretaries
in several places for reading and sending mail, and preparing or editing
ascii text files. (Such people don't need key sequences such as
"ESC CTRL-q p 3" to cause the computer to sing and dance.)

Emacs was, I believe, mostly designed originally by computer whizz-kids
for computer whizz-kids, and was SUPERB for many of them. (Though I've
met expert computer users who strongly dislike it, including people who
have contributed to this discussion.)

Both VED and Emacs have evolved a great deal over the last ten years and
can have very different flavours when set up by different users. Both
have great advantages over many other editors (on account of their
programmability, which, for example, makes it easy in VED (as in Emacs)
to give net-news readers the option of following up subject lines or
following up author's contributions, and would make it possible, if
anyone cared, to read a threads database to follow chains of news
article identifiers.)

Nowadays the interface to VED lags far behind what's possible with
windowing systems, which is why XVed was developed (though it stlil has
serious flaws from the point of view of some users, and in particular it
generates too many windows for some, and its menu interface is too hard
to extend or modify dynamically, which is why I have developed a quite
different one for use by beginners -- though so far it works only under
OpenLook).

But arguing about the pros and cons of particular editors is utterly
pointless. There will NEVER be agreement in taste on these matters, so
users should have a choice.

At present the choice for Poplog users is either
(a) to use a VED that's fully integrated with Poplog (so that programs
can write into or read from a VED buffer), or
(b) a tiny emulation of Emacs that is equally integrated but is
unacceptable to experienced Gnu-Emacs users (i.e. LIB VEDEMACS), or
(c) an interface from gnu emacs that does not support full integration
with Poplog.

All three options fail to support those who prefer some totally
different editor, e.g. vi (as Steve Knight has pointed out). No doubt
there are other editors. (I don't know how accurately LIB VEDWORDSTAR
emulates wordstar. I suspect it's only a small subset of facilities.)

It is going to be IMPOSSIBLE to develop and maintain VED emulations for
all the widely used editors, or even for Emacs, and proposing this is
just silly.

Therefore what is needed is (A) a collection of hooks to permit any
editor with sufficiently rich programming capability to interact with
Poplog on a client server basis, and (B) a simpler interface for the
more primitive editors.

(A) The client server model: This requires development of a rich
protocol (compare NNTP for newsreaders) so that a remote editor can
exchange messages with Poplog about the contents of the current editor
buffer, about which buffers the editor has, etc. There should be ways in
which the editor can tell poplog to compile a file, to compile a stream
of characters that the editor will send (up to some agreed terminator),
or to run an arbitrary procedure.

Also Poplog should be able to ask the editor which character is at a
particular location in a particular line, where the marked ranges are,
etc. It should be able to ask the editor to change the contents of the
current buffer, to start up a new buffer with a new file, to search for
a line with particular contents, to copy one bit of a file into
another, etc.

It would be an interesting research topic to design a protocol rich
enough to support all the desired interactions, e.g. so as to support
packages like lib showtree, and the prolog library(tracer), as well as
things like load marked range, load current procedure, and the
facilities for manipulating rectangular text blocks in LIB VEDBLOCKS
(see HELP VEDBLOCKS), as well as the mechanisms for supporting different
categories of browsable documentation with hypertext-like capabilities
(see HELP VEDGETSYSFILE).

With such a protocol Poplog could supply two executables, one with VED
and one without for use with the compilers. The VED version (which would
contain only Pop-11 for those who wish to extend VED) could then
interact with the other version, possibly over a network. Equally the
compilers could be driven by Emacs (with a set of utilities for handling
the protocol). Other programmable editors could also drive Poplog on
this model.

(B) The simple interface for non-programmable editors.
Before we had VED, Pop-11 users on the PDP-11/40 computer used to use
first of all the very primitive Unix ED interface (precursor of vi) and
then later a screen editor called DED (derived from one with a similar
name developed at Queen Mary College as it then was). Users would
interact with their programs by typing directly to the compiler, but
there were macros (nowadays syntax words would be used) that could be
used to load a file or invoke an editor.

E.g "ed foo.p" would spawn a Unix sub-process to run the editor on the
file foo.p, and when the process returned Pop-11 would compile the file.

This is not very different from the way many Unix utilities (e.g. unix
mail) invoke editors, using the value of the environment variable
$EDITOR (or $VISUAL).

A collection of such syntax words in Poplog languages would allow a
variety of interactions with editors. E.g. "help foo" could spawn a sub
process in which the editor was run with the relevant file, but no
attempt would be made to compile it when the editor returned. Different
environment variables could name different editors to be used for
different purposes, e.g. editing a file, examining documentation,
producing documentation. Also, in some cases the editor might be left
visibly displaying a file concurrently with continuing interaction with
Poplog. Teaching examples would then have to use cut and paste across
windows.

A potential loss in mode (B) would be the ability to redo complex
commands after simple edits (as provided by "immediate mode" in VED).
But that would not be difficult to support with the help of cut and
paste. I.e. prepare your commands in a window in your favourite editor,
then select them with a mouse and feed them to the compiler in another
window. To redo, simply edit the original (after copying if you wish to
save the previous interaction) then repeat the operation.

(I hate switching between mouse and keyboard, so that procedure would
drive me up the wall, but I am aware that there are many people who like
using a mouse as well as keyboard.)

Another possibility with new shells (e.g. tsh) and also DCL on VMS is to
use the inbuilt editor in the command interface (or terminal handler).
Some of these now allow you to edit and redo commands without too much
effort, by treating the current command line as a one line window into a
buffer of previous commands.

-----------------------------------------------------------------------

Anyhow one thing is very clear: nobody is going to convert the world to
using VED or to using Emacs. Therefore (as Alan Montgomery once said to
me around 1985) it is essential for Poplog to be able support multiple
editors even if not all of them give the full benefits of VED or Emacs.

But since emulating all of them is out of the question, I believe the
only solution is to provide the two sorts of interfaces described above.

Designing them well will be much harder than implementing them!

Aaron