[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Sep 4 14:14:15 1993 
Subject:Re: emacs & ved; flame-bait. 
From:Steve Knight 
Volume-ID:930904.04 

[Boredom alert! 
       This is a long and mostly serious discussion of the "Why VED"
       thread.  I try to summarise my views at the end.
]

Tim writes:
> I disagree, I don't think that this issue should be kept off the new group. I
> believe that there is a lot of support around for separating the language from
> the editor.  Why do we have to be forced to use one particular editor? 

This is a good question and clearly of interest to a reasonable subset
of Poplog users.  And, despite being a content VED user, I believe that
the tight association between Poplog and VED is a major barrier to its
takeup.  And it doesn't matter how enthusiastic one is about VED, it
isn't spectacularly better than EMACS (yet).

Put another way, the close association between Poplog and VED deprives
users of a free choice of editor.  The loss of that fairly obvious benefit 
has to be justified in terms of superior functionality.  Furthermore, 
this association has a performance cost -- it is difficult to avoid
including VED into delivered applications.  And that is a major,
repeated criticism of Poplog.  (To anticipate a couple of responses to
this last point (1) POPC is no answer because of restrictions in
what can be compiled (2) although it is a ``false objection'' it is
nevertheless taken very seriously (3) having two base executables,
one for delivery and one for development is clumsy but workable -- just
much less simple than separating editor from interpreter.)


Tim then writes a list of supposedly positive points about EMACS.  This
is highly relevant since EMACS is the primary editor for software
developers.  My responses are not intended to start an editor-war but
to show that (so to speak) one man's likes are another's dislikes.

> + mode dependent key maps, and the ability to extend them and define your own.

In my view, a straight disadvantage.  It is trivial to create mode dependent
key maps in VED and no one does it.  It is a widely held view that such
mode dependencies make difficulties for users unless clearly visually
differentiated -- which is not the case in EMACS.  So I believe Tim is
arguing against the mainstream view and should present a case for mode
dependent key maps that justify the cognitive disadvantage.

> + the info system (and the ease of translation into postscript). A hierarchical
>   info system is much preferable to a flat one like the poplog help ref and
>   teach system. You end up going around in circles.  

Again, a preference expressed as an perceived advantage.  Hierarchical
help systems are, unless the search space is relatively small, very
difficult to navigate around.

I'd prefer to invert this point and suggest that the problem is not
about ``flat'' help systems but about the lack of distinction between
what I call SIGNPOST help files and ordinary help files.  In fact, I believe
there should be a new category of help files provided, whose purpose
is to provide an overview of the help system.  Such files do exist in
Poplog's help system but they are often strangely named, hard to find,
and out of date.

Instead, I believe that some signpost files should be constructed 
automatically.  Any help file should provide (a) a one-line summary
of its contents and (b) referenced-by links, which are pointers
back to signpost files.  With just these two additions (and they
are both optional) a useful directional level could be provided.


> + all commands are issued by simple combinations of C- and M- keys which:
>   + are the same across all gnu-emacs variants that I have encountered.
>   + are the same across all terminals (unlike ved where there seems to be a
>     different key map for each different terminal type (AHHHHHHHH). 
>   + are supported to some extent in most decent unix shells (tcsh, zsh, bash,
>     ksh) for substitution and command line editing. Also in some packages like
>     Framemaker. 
>   + make the finding out of key bindings C-h b, and function variable names C-h
>     whatever, very easy. 
>   + make use of sensible mnemonics for basic functions ([p]revious, [n]ext,
>     [b]ack, [f]orward, [d]elete, [k]ill, [y]ank, [w]ipe (?)), which make
>     learning and reapplying keys in different modes very easy. 
>   + finally if you really get stuck there is always the command line, so that
>     if you don't know the binding you can do M-x function.

This is a good point.  VED ought to have a core keyset that is the same
on every terminal.  Coincidentally, this is (at long last) being 
addressed.  In mitigation of the long wait, I can only suggest that
EMACs is not much of an advertisement for having a core subset.  However,
I think it does a reasonably good job given the constraints.  Basically,
a poor job is better than none.


> + the zillions of different modes that are available. I could go on about
>   these for ages, but a couple of key points:

Unfortunately, each of these modes needs to be addressed separately.
Having modes at all is a problem.  So what is it that we get in
recompense?

>   + modes for all the major languages (several dialects of lisp, C, C++,
>     Pop11, Perl, etc etc - and different styles for any particular language). 

Having a good language "mode" is attractive.  However, it isn't clear
why editing a programming language should be a mode -- only the
behaviour of the CR key is naturally redefined.  For example, suppose
I am constructing a Pop11 program inside a mail message.  I would
have a legitimate complaint if I didn't have access to my usual program
writing tools (and hence techniques).

After some experimentation with program language modes, I became
convinced that the only justification would be if (1) the mode
performed incremental syntax checking at CR boundaries and (2) 
incremental program layout and (3) token-sensitive searches.
For a good example, see Symantec's THINK Pascal, a real masterpiece.

Otherwise, I found that a collection of programming templates was
perfectly adequate and free of modal restrictions.


>   + threaded mail and news reader, also a choice of several other mail and
>     news readers

This is personal taste.  I don't ask my program or text editor to read
news.  I think the EMACS news reader is attractive.  But I do not decide
which editor to write my programs in on the basis of whether or not
I read news inside it.

Flipping this point around, EMACs users get the benefit of only having
one text processing environment -- because few news readers let you 
use any text editor you like.  In fact, I can legitimately (tho' 
ridiculously) complain that EMACS is another of these draconian
news readers that doesn't let me use VED to view/edit postings.

It's a rather weak point.


>   + a superb ftp mode (thanks to Andy Norman).

Granted.  Yet one can carp that if ange-ftp had been built as a C-library
rather than as EMACs code, every application could have benefited
from it.

Again, I don't expect my program or text editor to be an ftp browser.
I wouldn't say, "Gosh, Microsoft word can't do ftp.  I don't think
I'll use it for this letter."  


>   + a spread sheet (oleo).

Ditto.

>   + a full interface to ispell, which has saved my life on many occasions.

This is a worthwhile facility.  Presumably it would be straightforward
to build such a VED facility.


>   + an absolutely amazing LaTeX mode (auc-tex), with the only source level
>     LaTeX debugger I have encountered. Hacking LaTeX without this would be a
>     real pain in the.. 

My prejudices against LaTeX are extreme.  I refuse to take this point
serioiusly, even if I should.


> + full gnu-emacs exists on many different architectures and operating systems,
>   from the usual unix and vms machines down via PCs, MACs, onto the old
>   Ataris. I haven't got a copy for my Psion3 yet, but I am working on it..

Portability is an issue.  People may wish to use Poplog on one machine
and edit on another that cannot host Poplog.  However, this has been 
a rare demand.  


> + a tutorial is offered as soon as you startup emacs, unlike ved.

I have tried using this wretched tutorial many times.  It always ends
in disaster -- the screen split into a dozen different one-line
segments and lost in a maze of twisty little modes, all slightly
different.

My thoughts on this is that EMACs is intended to be
learnable by isolated individuals.  So they have tried to present a
self-tutoring mode.  Unfortunately, it is difficult to present a tutorial
that won't get novices into trouble.  

By contrast VED has some well-thought out teach files.  But they do
require some tuition and supervision.  

Neither approach is really adequate.  This seems like a nice area
for some educational research.

> + powerful regular expression matching facilities.

Coming to an editor near you, real soon now.  I've been using Jon Meyer's
excellent regular expression library for so long I've forgotten.  (I'd
check it was on the PLUG Archive but I can't access the disc right now
owing to ``upgrades''.)

Yes, regular expressions are very nice.  If Jon's stuff doesn't go
into Poplog 14.5, then my worst suspicions will be confirmed -- I'm
trapped in a universe that's gone insane.

> + elisp.

A disadvantage, relative to VED.  Of course, elisp is very nice
compared with almost any other editor.


> + it is free.

And once one has paid for Poplog, so is VED.  So this point boils
down to two subpoints
   (a) Would Poplog be cheaper if VED was unbundled?
   (b) EMACs is widely used and understood because it is free.
Since (a) is impractical, we'll never know.  But in principle the
answer is ``yes, eventually, after the cost of unbundling is
amortised''.  The second point, however, is very strong.

The fact that EMACs is so widely used, in comparison with VED,
is the strongest point in the debate.  By sticking with VED we
are condemning a significant fraction of potential developers
to a dual learning curve -- both a new language and a new 
editor.  Furthermore, many of these developers perceive the
ability to choose their own editing environment an indicator
of quality.  They may be misinformed (they are in my view) but
I claim that is the prevalent view amongst many of the people
we would most like to be using Poplog.


> + it is faster than ved to start up from scratch, and even with a large
>   customisation setup, you can byte-compile it to keep the time down. 

I have to flatly disagree with Tim here.  I know of no reason why there
should be the least difference.  There certainly isn't on our site.  It
seems that Tim's system is incorrectly configured.

> + many thousands of users world wide, so no matter where you are, there is
>   lots of local support and FAQs and self help groups. 

See above -- a strong point.

> + robustness. Better multiple buffer handling. Multiple windows on the
>   same buffer (ved can't do that).

I'll treat this as three points.  Robustness is the most serious issue.  I
am perhaps an odd-man out in having core-dumped EMACs more times than 
I've successfully quit it (don't ask me why -- everyone says it can't
happen.)  However, the two-process model of EMACs isolates the editing
work from the possibility of a Poplog crash.  And this latter possibility
is more and more likely with the inclusion of the flakey X-toolkit.

Robustness through process separation is the second strongest point in 
Tim's argument, almost as compelling as the voting-with-feet argument.
What VED gets in return is superior interactivity.  However, this is
an incredibly weak argument to someone who just lost three hours
work because XVED decided to crash for no apparent reason.

The second point concerns buffer handing.  The two systems seem
identical to me, so I'll have to leave this hanging until Tim
elucidates.  

The third point is multiple views on the same file.  Clearly an advantage.
I've never understood why this cannot be added to VED -- there are only
two issues.
  (1) how is it done?  Well, this is just a SMOP (Small Matter of Progging)
  (2) how does a user select a particular view of a file?  Again,
      a SMOD (Small Matter of Design).  It is especially easy in
      the context of XVED.

Tim then continues by pointing out one aspect in which VED is
a better editor:
> In the interest of presenting a balanced argument :-) , one criticism with
> emacs would be the way that it doesn't show up marked regions like ved does -
> very irritating..

Of course there are many minor discrepancies between VED and EMACs
in which one or the other is slightly superior.  In my view, the marked
range debate is absolutely typical of the difference between the
two editors.  VED has the simpler concept with good awareness of 
human-interface issues.  EMACs has the more powerful concept but 
implements it with no visual feedback.  (This is not true of XVED
that has both marked ranges *and* selections.  Good grief.)

Other such illustrative issues are cursor handling when the logical
position is beyond the end of line; association between file, buffer,
and view; help system; split screen management, and so on.


One further point concerns support for using VI.  Many students
leave college having mastered VI and no other editor.  Support
for VI would be reasonably straightforward to provide.  Firstly,
the help/ref/etc commands would bring up VI in read-only mode.
Secondly, one would add a VI command that edited a file and on
exit (optionally) loaded it.  Thirdly, I'd write some VI commands
for getting hold of Poplog help files.  (And lastly, I'd go and talk to
a few VI hackers and made sure that that was the sort of thing they
wanted.)

Opponents might argue that this is so much less satisfactory than
putting in the small amount of effort to learn VED, that there is
no point in such support.  In defence, I would argue that the spread
of Poplog beyond its current parochial boundaries largely depends on the
ability of individuals to learn the system *unassisted*.  For example,
I have Poplog users who use VI and only VI -- simply because the
experienced Poplog users cannot spare the time to tutor them in VED
(and we would fail anyway because they are so happy with VI).


Summary
-------

Trying to bring these strands together I see the debate being about
making Poplog an open-editor system.

* A closed-editor system means that new users
  are given two learning tasks -- a language and an editor.

* A closed-editor system means that many experienced developers
  are isolated from powerful editing tools they are familiar and
  strong in.  They also associated being closed with low-quality.

* A one-process system leads to fragility.

* The two most popular editor for software developers under UNIX
  are EMACs and VI.  It should be straightforward to provide proper
  support for both of these without any changes to VED (although
  a little to Poplog, so that EMACS can conduct a dialog with 
  Poplog about where help files are kept.)  This relatively
  inexpensive step would almost wholly remove the perception of
  being a closed-editor system.

* What makes Poplog a closed-editor system is the inaccessibility
  of the help/ref/teach/etc files to other editors.  One way to cure
  this would be to separate the help system from Poplog (e.g. make
  the help system a bunch of C-library routines.)

Steve