🚀 go-pugleaf

I'm _not_ ranting for the sake of ranting, I swear!

wyle@inf.ethz.ch writes:
> 1)  Availability: vi(1) is available on every unix box I touch.  I don't have
>     to INSTALL it FIRST!!
No such guarantee exists for Emacs.  Note that porting GNU to standard unixes
and machine types is usually fairly easy.  The smaller emaxen are surely
easier, but I don't have experience with them.  It's also been ages since I
last encountered a machine which didn't have an emacs already installed
(usually GNU's).

> 2) Support: vi(1) is supported by the VENDOR of the boxes I manage.
GNU Emacs is provided and supported (in a limited sense) by FSF (a top-notch
software shop), free of charge.  Free, fast, expert, and friendly support can
be found on the Usenet in gnu.emacs and comp.emacs.  `Vendor support' is not
quite a contradiction in terms, but ...  1/2 :^)  Also consider that vi is
relatively static.  It doesn't _require_ any support, and neither does cat(1).

> 3) Consistency: All vi(1) implementations I've touched are consistent in
>    user-interface, command syntax, cursor movement, ...
So is every installation of a given program, including GNU Emacs.

> 4) Speed: vi(1) starts running faster.
Undoubtedly.  But how often do you start an editor?  Not once for each file, I
hope.  I'll start one, maybe two, for an entire extended session when pressed
for machine time.

> 5) Safety: vi(1) journals, recovers automagically after a system crash.
GNU Emacs makes frequent backups and checkpoints, providing similar security
from crashes.  Following this vein, Emacs also provides version control and
automatic recovery from (what appear to be) user and filesystem errors.

> 6) Size: vi(1) is small, comes with the OS, needs no extra disk space.
Granted.  GNU Emacs is a big boy.  BTW, where's the on-line documentation and
help?  Distributed libraries of neatnesses (see 11)?  (I'm not even going to
get into the resulting order-of-magnitude difference in functionality.)

> 7) Management: vi(1) needs NO system management effort.
Not so for emaxen.  Like any non-static program, they need to be installed
_once_, then updated as improved versions are released.  I've done it, which
means any idiot can do it.  :^D

> 8) Macros: vi(1) has a simple, powerful macro language not requiring the
>    user to know and love LISP.
vi has a gross and ugly macro language, I'll wager few will ever learn to love.
Try Lisp, you may like it.  Beats the hell out of standard 4th generation
general purpose languages, like (gak) C and (ulch) Fortran.

> 9) Terminal support: vi(1) will run on any terminal, including paper
>    teletypes.
Emacs is a visual editor, and requires a display.  I'm guessing that vi users
rarely (if ever) use it in line mode.  As for paper terminals, remember that
this is 1989.  (Do I glimpse a memory of Dec20 emacs having a line-mode as well
as a visual one?)  To the best of my knowledge, GNU Emacs runs well on most
terminals, but I haven't played with any of the wierd ones in a bit - I dunno.

> 10) Bug-free operation: vi(1) does not leave zombie processes,
A small and infrequent price to pay for sophisticated process management.

>     open a window on the console when you're remotely logged in, leave a user
>     in your login directory after you log out,
Elaborate.

>     leave garbage backup files around,
You miss the point.  These are not garbage, they are part of the default
security.  If you don't want them, don't create them.  (GNUsers, see the
variables version-control and auto-save-interval).

>     dump core, etc.
Yow.  Who's doing this?

> 11) Inertia: I've used vi(1) for a few years, have built up a large
>     family of macros for shell-script programming, troff text, and modula-2.
>     With continued commitment from vendors for support, why change?
I've used GNU Emacs for several years.  Libraries of all kinds of neatnesses
such as above are part of the distribution (see 6), and new ones frequently
come over the net (see 2).  Why change?  Because it's so much more powerful.

Regards, [Ag] gaynor@rutgers.edu