Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsd!rutgers!aramis.rutgers.edu!athos.rutgers.edu!gaynor From: gaynor@athos.rutgers.edu (Silver) Newsgroups: comp.editors Subject: Re: Editor Wars Keywords: editors, vi Message-ID: Date: 15 Apr 89 15:52:03 GMT References: <175@hcr.UUCP> <587@alice.marlow.uucp> <4048@ttidca.TTI.COM> <960@myrias.UUCP> <24@hcr.UUCP> <4129@ttidca.TTI.COM> <194@xochitl.UUCP> <156@inf.ethz.ch> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 79 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