[comp.unix.questions] vi and emacs questions : summary of replies

paul@cantuar.UUCP (P. Ashton) (08/07/88)

Some weeks ago I posted a question about vi and emacs. I asked about
whether it was practical to run GNUemacs in a student environment
on a VAX 11/750 running 4.3BSD, and SUN 3/50s and 3/60s given that
we'd heard GNUemacs was quite resource hungry, and whether there was
a version of vi for VMS. I got several replies (too many to put into one
posting) thanks to all those that responded.

GNUemacs resource requirements - most replies said that GNUemacs uses a
lot of CPU and memory, and that they don't use it on machines as small
as a VAX 11/750 for students. Many smaller emacs were suggested as
alternatives, including microemacs (comp.sources.unix archives), JOVE
(4.3 bsd user contributed software tape), and MicroGNU (now called mg - not
sure how to get hold of it). One person reported running up to 10 emacs
users on a VAX 11/780 running 4.3BSD, but didn't specify which version
of emacs he was running.

Vi on VMS - the only implementation reported was as part of the UNIX
environment for VMS from Interactive Systems and Wollongong (the
person didn't know how to contact the vendor however). This information
was sent to me by davidsen@steinmetz.ge.com (William E. Davidsen Jr) so
anyone interested in pursuing this may be able to get some more info from
him.

As for which editor to use next year - we have decided on some form of
emacs - probably microemacs. We believe (as did all of the people who
expressed an opinion in their mail messages) that emacs is the better
editor, and is more widely available over different operating systems
than vi. One person replied that Unix programmers have to know vi, and
that emacs should only be taught to people who already know vi. However
we are a CS dept which offers degrees in Computer Science, not an
institution for turning out Unix programmers, so this argument wasn't
really applicable.




-- 
Internet(ish):  paul@cantuar.{uucp,nz}  JANET/SPEARNET: p.ashton@nz.ac.canty
UUCP:              ...!{watmath,munnari,mcvax,...!uunet!vuwcomp}!cantuar!paul
NZ Telecom:     Office: +64 3 667 001 x6350
NZ Post:        University of Canterbury, Christchurch, New Zealand

allbery@ncoast.UUCP (Brandon S. Allbery) (08/10/88)

As quoted from <626@cantuar.UUCP> by paul@cantuar.UUCP (P. Ashton):
+---------------
| Vi on VMS - the only implementation reported was as part of the UNIX
| environment for VMS from Interactive Systems and Wollongong (the
| person didn't know how to contact the vendor however). This information
| was sent to me by davidsen@steinmetz.ge.com (William E. Davidsen Jr) so
| anyone interested in pursuing this may be able to get some more info from
| him.
+---------------

There's a vi emulator for TPU in the comp.sources.misc archives.  It was
posted before the volume/issue stuff was implemented, so its name may not be
standard, but the X-Archive: is 8710/vms-vi/nn where nn = 1 to 13.

++Brandon
-- 
Brandon S. Allbery, uunet!marque!ncoast!allbery			DELPHI: ALLBERY
	    For comp.sources.misc send mail to ncoast!sources-misc

madd@bu-cs.BU.EDU (Jim Frost) (08/10/88)

In article <626@cantuar.UUCP> paul@cantuar.UUCP (P. Ashton) writes:
|Some weeks ago I posted a question about vi and emacs. I asked about
|whether it was practical to run GNUemacs in a student environment
|on a VAX 11/750 running 4.3BSD, and SUN 3/50s and 3/60s given that
|we'd heard GNUemacs was quite resource hungry [...]

|GNUemacs resource requirements - most replies said that GNUemacs uses a
|lot of CPU and memory, and that they don't use it on machines as small
|as a VAX 11/750 for students.

The 750 here had emacs as it's main editor; with 10 students all
running it its performance was less than optimal, and more than that
become unbearable.  A typist that didn't need to look at what s/he was
typing could handle the slowness; it was too much of a bother for
others.  If your expected load is about 5-6 users (that's about what a
750 can handle anyway :-) then it's not too bad.  A smaller editor is
suggested.

| Many smaller emacs were suggested as
|alternatives, including microemacs (comp.sources.unix archives), JOVE
|(4.3 bsd user contributed software tape), and MicroGNU (now called mg - not
|sure how to get hold of it).

I would recommend not using JOVE.  I had the unfortunate task of
trying to port that to a Silicon Graphics 4D; I can't believe how ugly
some of that code is and will no longer trust my work to it.  Perhaps
newer versions are better but due to the number of silly things done
throughout the code, I doubt it.  Microemacs is cleaner, has more
functions, and shouldn't hurt your performance at all.

|One person reported running up to 10 emacs
|users on a VAX 11/780 running 4.3BSD, but didn't specify which version
|of emacs he was running.

If it's any of the newer versions it probably doesn't matter; there
are more functions in the new versions, and bug fixes, but unless
you're a power emacs user it doesn't really matter.  Newer versions of
emacs have nicer screen manipulation, which is a real boon if you're
dialed in at 1200 baud, but little seems to have changed from the
average user's standpoint and there don't seem to be any marked
differences in machine usage.

|One person replied that Unix programmers have to know vi, and
|that emacs should only be taught to people who already know vi.

There's a lot of that attitude and I think that's too bad.  Vi is nice
enough for entering a lot of code at one time but is very cumbersome
for minor changes.  For this you want a point-and-type editor (such as
emacs).  Having mnemonic commands makes people happy, too (although
I've found that the efficiency of the emacs command set is far below
the non-mnemonic command set of wordstar).  Given the wealth of (free)
editors for UNIX, I'd recommend steering newcomers away from vi for
the most part.  A small introduction to it is a very good idea since
many programs will call up vi by default.  Since the :q command isn't
what I'd try first to get out, it's nice to know at least that much.

Happy hacking,

jim frost
madd@bu-it.bu.edu