[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Sep 4 18:51:32 1993 
Subject:Re: emacs & ved; flame-bait. 
From:Tim Read 
Volume-ID:930904.07 

>>>>> On Sat, 4 Sep 1993 14:14:15 GMT, sfk@uk.co.hewlett-packard.hpl (Steve Knight)  said:

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

Good, we definitely agree there.

>> + 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..
                                               ^^^^^^^^^^^ 
Widely held by whom? The beauty of the modes are that they protect novice
users from some of the more dangerous facilities available in some modes. Once
in a particular mode a user can start off by using the simple facilities like
auto-indentation, and then start to make use of the extra power that is
provided. I can't be bothered to run off a list of all the features that
particular modes can provide.

> 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 have never had any problems with the info system. Each subject has both an
easy to use menu and an index, together with cross references; and it is easy
to get back up the hierarchy.

> In mitigation of the long wait, I can only suggest that
> EMACs is not much of an advertisement for having a core subset. `

Why? This is just your personal prejudice here. I think that the core movement
commands make perfect sense, as I noted previously:

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

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

The CR remapping is the smallest part. There is also (depending on the
language), function name completion, a link to tags for accessing functions in
different files with no effort, compiling facilities with simple debugging as
standard, not to mention hooks to more powerful debuggers, template insertion
etc. Language modes are just a part of what modes are available.

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

The same argument holds for news as does for mail. What if you want to post a
bit of code to this group, do you develop it in an editor, save it to a file
and load it into your news reader to send it? Also you have to learn a new
interface for each package. In emacs most modes use similar key bindings for
similar tasks. Also if you get stuck, how to get unstuck, get help etc is the
same as it is for any other mode within the editor. What really bugs me is
when I am forced to use some new package for something, then when things get
unpleasant, I have to search around to try and negotiate the help system...

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

You are in a minority then. A large proportion of people use TeX or LaTeX to
produce their papers etc. 

> + it is free.

> And once one has paid for Poplog, so is VED.  So this point boils
> down to two subpoints

Yes but I can't get Poplog for my PC. Much as I might like to...

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

Yes, good points.

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

Sorry Steve. I am not sure how to run an accurate test on speeds, but just
using my stop watch, the start up time is as follows (from entering the
command to the start up screen appearing):

emacs (average of three attempts)  2.15 seconds
ved (average of three attempts) 7.18 seconds

If anything my emacs should be *MUCH* slower, as I am loading in a great big
byte compiled elisp start up file. Please do the same on your system for a
comparison. I would doubt that it is our system here, as you know Aaron set
the poplog stuff up. Mind you, it is probably you emacs that is incorrectly
set up.

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

I'll resist the unprofessional comment about HPUX... Mind you one thing I can
legitimately say is grief caused by the position of the control keys on the
keyboards of our HP X terminals.  

> ... an incredibly weak argument to someone who just lost three hours
> work because XVED decided to crash for no apparent reason.

Tell me about it. I have Xved crash on me in such a position... 

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

Sorry if I was not clear about this. I only meant that it is possible (easy)
to split emacs buffers both vertically and horizontally - very useful at
times. May be I am wrong about this, but I thought that ved could only split
into two buffers vertically (I am not counting Xved, I know it forks new
buffers - too many!).

Ok this is less useful now in the days of the workstation and windows all over
the place, but when I learned emacs, we only had vt52 terminals. In such
circumstances multi windows were extremely useful.

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

On a related point, if windows NT is going to be taking the market place by
storm (?) then Poplog will have to run under that environment. As any windows
person will know, the look and feel of packages under NT are the same. I would
suspect that people using it under NT would NOT put up with ved (or emacs for
that matter). It would hence seem likely that Poplog will have to conform to
the same look and feel.  Another reason to separate the editor/interface from
the environment..

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

Ok, so whilst I disagree with some of your points about emacs, these are
largely irrelevant in the end, if we agree that such a subject as editors will
never be resolved, and what is important are the points you bring out in your
summary; which I agree with. So lets make Poplog an open-editor system!

I am away now for a week at a workshop, so it will be interesting to see how
this thread has shaped up when I get back...

 Tim




--
   ---------------------------------------------------------------------
   Tim Read, Email: tmr@cs.bham.ac.uk, The Attention and Affect Project, 
   Cognitive Science Research Centre, School of Computer Science,
   The University of Birmingham, Edgbaston, Birmingham, B15 2TT, England
   Phone: +44-(0)21-414-4766, Fax: +44-(0)21-414-4281
   ---------------------------------------------------------------------