cheeks@mars.xochitl.UUCP (04/07/89)
You can pick your friends, and you can pick your nose. And sometimes you can even pick your friend's nose. But you can never, never, NEVER pick your friend's editor! Just an observation from someone who finds editor wars silly. You may now resume the previously scheduled religious war. Cheeks
pavel@dgp.toronto.edu (Pavel Rozalski) (04/10/89)
I have a modest proposal to make (with apologies to J. Swift).
Periodically, the eternal debate over which editor to use crops
up. The emacs-style editor users expound on the functionality and
expandability of their editors. The vi users like ease of use and
widespread availability of vi. The ed group mumble something rude
about real men (er, programmers) don't use visual editors and
everything useful can be accomplished with ed. These are the initial
arguments used. Soon after a religious battle ensues with each faction
calling other factions rude names. The debate has been known to end up
with a brawl of computer types kicking and screaming, trying to
physically prove that one editor is better than the next.
I would like to propose a simple solution to end these feuds. I
suggest that we enter all our files with:
cat >foo
The advantages are numerous.
Everything that one would wish accomplish can be done with this. Any
file or program can be easily entered. There is an added onerous of
getting the text or program right on the first try. Users would
ponder more on the meaning and correctness of each line before
foolishly typing return. The decision of whether to modify (that is
rewrite and clobber) an old file would also be taken with more
gravity.
When editing programs, programmers would find it useful to split a
larger program into many smaller source files, perhaps with one
function or procedure per file. This would lead to very modular code.
New users would have very easy time adapting to the commands - there
really are none. There is the delete key and return key which most
users are quite used to. The only extra function is the
exit-editor-and-save-file command which is almost always defined to be
Control-D. No heavy concepts such as backup files, cursor movement
(let alone page up or page down!), editing multiple files, many
confusing modes, regular expression matching, macro definitions, etc.
Simple.
cat is, as far as I know, guaranteed to run identically on all UN*X
systems, and then probably some which do not even run UN*X (there are
probably functional equivalents in most OS's). There would be no need
to port it to every new UN*X system as it would probably already be
installed.
cat is not a strain on system resources. It does not eat up much CPU.
Upon examining some files on our system (Sun 3's, running SunOS 3.5) I
found the following:
-rwxr-xr-x 1 root 24576 Nov 10 1987 /bin/e
-rwxr-xr-x 1 root 24576 Nov 18 1987 /bin/ed
-rwxr-xr-x 1 root 32768 Sep 4 23:53 /usr/local/ed
-rwxr-xr-t 1 root 131072 Nov 18 1987 /usr/ucb/vi
-rwxr-xr-x 1 root 204800 Oct 17 20:58 /usr/local/jove
-rwxr-xr-x 1 root 868352 Sep 5 18:38 /usr/local/emacs
And of course:
-rwxr-xr-x 1 root 18644 Nov 10 1987 /bin/cat
This program takes up very little disk space. It has no support files
or programs. I suspect there is a version in the public domain. It
would probably be never swapped out. cat could probably be further
hacked to optimize for editing speed and reduce the size by taking
out all those undesirable features added to cat since UN*X left Bell
Labs.
So I make this proposal to competent system administrators everywhere:
Remove all those other editors. Try cat for a while. I firmly believe
it will make your system a more memorable one.
Pavel Rozalski
UUCP: ..!uunet!dgp.toronto.edu!pavel
BITNET: pavel@dgp.utoronto
EAN/X.400: pavel@dgp.toronto.cdn
INTERNET: pavel@dgp.toronto.edusiebren@cwi.nl (Siebren van der Zee) (04/10/89)
In article <8904101515.AA04069@explorer.dgp.toronto.edu> pavel@dgp.toronto.edu (Pavel Rozalski) writes: > I would like to propose a simple solution to end these feuds. I >suggest that we enter all our files with: >cat >foo > >The advantages are numerous. You forgot ONE thing that complicates this editor: you have to cat -n to type BASIC programs :-) Siebren, siebren@cwi.nl
wyle@inf.ethz.ch (Mitchell Wyle) (04/11/89)
In article <194@xochitl.UUCP> cheeks@mars.xochitl.UUCP writes: >And sometimes you can even pick your friend's nose. >But you can never, never, NEVER pick your friend's editor! >may now resume the previously scheduled religious war. Thank you; we shall.... ;-) The big boss, his pals, and all other people weilding the mega-Francs here hate vi(1). "Vi is not an editor; it is a disease." They use emacs or a macintosh, when their secretaries don't type for them. I however, use vi almost exclusively. I have not yet ported stevie to my CP/M machine, but when I do, it's goodbye wordstar! There are times when the "modi" of vi make me angry, and other times when I'm thankful for them. I have been gathering macros, experiences, and help from the usenet postings defending vi, but have not yet incorporated some of the good habits into my vi usage. I don't move around by paragraphs { } or by sentances ( ) as quickly or as well as I would like; I hardly ever mark, bound, copy, paste using buffers :-(. However, I often write one-time macros instead of sed programs. I have accumulated some nice macros in my .exrc, and recommend to serious unix people to use vi instead of emacs. Here (again) are my 11 reasons for using vi: Why I use vi: 1) Availability: vi(1) is available on every unix box I touch. I don't have to INSTALL it FIRST!! 2) Support: vi(1) is supported by the VENDOR of the boxes I manage. 3) Consistency: All vi(1) implementations I've touched are consistent in user-interface, command syntax, cursor movement, ... 4) Speed: vi(1) starts running faster. 5) Safety: vi(1) journals, recovers automagically after a system crash. 6) Size: vi(1) is small, comes with the OS, needs no extra disk space. 7) Management: vi(1) needs NO system management effort. 8) Macros: vi(1) has a simple, powerful macro language not requiring the user to know and love LISP. 9) Terminal support: vi(1) will run on any terminal, including paper teletypes. It needs no windows, graphics, or special features. The configuration of Unipress emacs here can't work with an adm3a. vi has special environments for low baud rates; emacstool is a pig. 10) Bug-free operation: vi(1) does not leave zombie processes, open a window on the console when you're remotely logged in, leave a user in your login directory after you log out, leave garbage backup files around, dump core, etc. as some delicious flavors of emacs do. 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? -- -Mitchell F. Wyle wyle@ethz.uucp Institut fuer Informationssysteme wyle@inf.ethz.ch ETH Zentrum / 8092 Zurich, Switzerland +41 1 256 5237
amanda@iesd.dk (Per Abrahamsen) (04/13/89)
In article <156@inf.ethz.ch> wyle@inf.ethz.ch (Mitchell Wyle) writes: > Here (again) are my 11 reasons for using vi: Again, 11 reasons to use `cat' as your editor... -- Per Abrahamsen, amanda@iesd.dk, {...}!mcvax!diku!iesd!amanda
nate@hobbes.intel.com (Nate Hess) (04/14/89)
In article <156@inf.ethz.ch>, wyle@inf (Mitchell Wyle) writes: >Why I use vi: >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? Gosh. With this line of reasoning, I'm surprised you're still not programming in COBOL. :-)# --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes woodstock@hobbes.intel.com ...!{decwrl|hplabs!oliveb}!intelca!mipos3!nate
gaynor@athos.rutgers.edu (Silver) (04/15/89)
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
nmm@apss.ab.ca (Neil McCulloch) (04/17/89)
In article <23162@agate.BERKELEY.EDU>, ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: > ... Why must this newsgroup, at intervals > of roughly six to eight weeks, go through a round of "only a shithead would > use vi, only an asshole would use emacs" type of exchanges? Lot's of useful stuff comes out of such discussions, especially for novice users. Certainly, editors are the most basic interative tools users use. And certainly, they seem to about the worst documented. So, although it pains you, and perhaps a lot of others, and maybe you've heard it all before, it's certainly useful. In my experience, the best way to kill a discussion that no longer has a useful S/N is to change the subject. As it happens, this editor wars is a recurring one for very good reasons. Perhaps someone would post a summary of where vi is the best tool, occasional editting of ascii files, small files and so forth, and where emacs is best, programming, multiple files, constant editor use and that sort of thing. I sure that would be useful. neil
wyle@inf.ethz.ch (Mitchell Wyle) (04/17/89)
In article <1715@iesd.dk> amanda@iesd.dk (Per Abrahamsen) writes: >> Here (again) are my 11 reasons for using vi: >Again, 11 reasons to use `cat' as your editor... Although somewhat absurd, this point is well-taken; reason 8, (simple macros, not requiring knowledge or love of LISP) however is not a reason to use cat, unless cat has macros I don't know about. I use cat -s to eliminate extra blank lines. BTW: Has someone ported Stevie to CP/M? -- -Mitchell F. Wyle wyle@ethz.uucp Institut fuer Informationssysteme wyle@inf.ethz.ch ETH Zentrum / 8092 Zurich, Switzerland +41 1 256 5237
wyle@inf.ethz.ch (Mitchell Wyle) (04/22/89)
This is my first posted reply to a flame; I hope the useful info in this article off-sets the counter-flame. In article <23162@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >Maybe because I'm an historian, I can remember events earlier than 8:00 am >[..] >This newsgroup must have one of the highest bull shit to useful information >ratios of any newsgroup outside of the soc.culture.you-name-it groups. In >two years of "reading" this group, I've only seen three or four postings >that caused me to exercise the third finger of my left hand (s) rather than >the first finger of my right hand (j). Maybe our feed is filtered and we get only the good articles. ;-) I have to disagree. I have collected a lot of wisdom from this group, and 81 Kbytes of vi macro code, vi quick reference manuals, tips and tricks. Consider the "transpose case macro" discussion with such gems as: map V :s/\([a-z]*\)\([A-Z]*\)/\U\1\L\2/g^V^M map v mxdwO^VpV0D:d^V^M`xP`x and map ^T i^M^[Ea^M^[-y$Pa^M^[-:s/./\~/g^M"zd$+@z--4J map ^T i^M^[Ea^M^[-y$Pa^M^[-:s/^[ ]*//^M:s/./\~/g^M0"zd$+@z--4J What about the insert mode macros posted for public use? se ai sm ts=3 sw=3 prompt " " Map insert mode keys map! #in #include map! #de #define map! #un #undef map! #el #else map! #en #endif not to mention my own "electric modula-2" macros with such useful gems as: map ;pr iPROCEDURE proc(vars) : BOOLEAN;^V^M(* PreConditions: *)^V^M(* PostConditions: *)^V^MEND proc;^V^M^V^[kkkkwcw and map ;if iIF ( cond ) THEN^V^M statement ^V^MEND;^V^M^V^[kkkwwcw map ;ie iIF ( cond ) THEN^V^M statement ^V^MELSE^V^M statement2^V^MEND;^V^M^V ^[5kwwcw map ;ii iELSEIF ( cond2 ) THEN^V^M stmnt2^V^MELSEIF ( cond3 ) THEN^V^M stmnt3 ^V^M^V^[ map ;ca iCASE var OF^V^M case1 : stmnt1 ^V|^V^M case2 : stmnt2 ^V|^V^Mcase3 : stmnt3^V^M ELSE default^V^MEND; (* case *)^V^M^V^[ * * * How can you complain when we (admittedly occasionally) see such useful information? >How about a vote. How many readers want to read postings of the form If you can't stand the noise and flames, get off the net. Don't complain about postings devoid of useful information if your own article is a self-reference. >(a) I use vi and think anyone who uses emacs must have escaped from > from "sheltered employment." >(b) I use emacs and think anyone who uses vi must have to register > with the local parole board. (c) I use both; here are some helpful macros for beginners and advanced users. >If the majority selects (a) or (b), so be it. I also know how to use the "u" >command! Do you always advertise to the *entire* net before you push the u button? -- -Mitchell F. Wyle wyle@ethz.uucp Institut fuer Informationssysteme wyle@inf.ethz.ch ETH Zentrum / 8092 Zurich, Switzerland +41 1 256 5237
ked@garnet.berkeley.edu (Earl H. Kinmonth) (04/23/89)
In article <175@inf.ethz.ch> wyle@ethz.UUCP (Mitchell Wyle) writes: >This is my first posted reply to a flame; I hope the useful info in this >article off-sets the counter-flame. Keeping the Yin and Yang in balance.... >tricks. Consider the "transpose case macro" discussion with such gems One person's gem is another's dross. >How can you complain when we (admittedly occasionally) see such useful >information? Because other groups provide even more useful information with less drek. >If you can't stand the noise and flames, get off the net. Don't >complain about postings devoid of useful information if your own >article is a self-reference. In lieu of a editors.d group, complaints must of necessity be posted here. If a certain amount of useful information is a prerequisite to posting, I can provide the code to "ked," a clone of ex that works on keyed logical records. Paired with "kawk", a C-interpreter (also written by me), it makes a file-management system especially suited to multi-lingual bibliographies. Since there are several megs of code involved, I should be able to justify a few lines of pissing and moaning. :) :) >Do you always advertise to the *entire* net before you push the u button? Why not? Silent withdrawl is hardly an effective protest in a medium such as this.
barnett@crdgw1.crd.ge.com (Bruce G. Barnett) (04/26/89)
In article <175@inf.ethz.ch>, wyle@inf (Mitchell Wyle) writes: >" Map insert mode keys >map! #in #include >map! #de #define >map! #un #undef >map! #el #else >map! #en #endif I use to do this, but stopped because if I cut some text out of one window system, and pasted it into another window system, the "#include" would become "#includeclude". I started my expansion macros with a function key. -- Bruce G. Barnett <barnett@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]> uunet!steinmetz!barnett, <barnett@steinmetz.ge.com>
loo@mister-curious.sw.mcc.com (Joel Loo) (05/02/89)
In article <238@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce G. Barnett) writes: >>map! #in #include > >I use to do this, but stopped because if I cut some text >out of one window system, and pasted it into another window >system, the "#include" would become "#includeclude". You do not have to worry: the substitution will be done only if "#in" is followed by a <space> (this is how 'abbr' works.) "#include" will not be substituted. However, using of visible chars such as '#', ';' etc as prefixes to macros is not a good practice. You are right, we shd try using chars like ^X, ^V, <esc> etc. ObMacro: "Execute the current line as editor command": good for interactive macro/abbr testing. (Please replace control chars appropriately.) map ^Xm "dyy:@d^M E.g. type in the following line in a vi buffer: map ^P !}fmt on this same line press ^Xm a new macro ^P will get defined immediately. -- Joel