paul@cantuar.UUCP (P. Ashton) (06/28/88)
We are in the middle of deciding which editor to teach students next
year, and are looking at vi and emacs. We have a couple of questions
(i) we have heard emacs is somewhat resource hungry. What experiences do
people have with students using emacs with regard to resource use
(environment GNU emacs on a Vax 11/750 running 4.3BSD, and on sun 3/50s
and 3/60s).
(ii) is vi available for VMS (if so what are the details)?
Please reply by email - I will post a summary.
Paul Ashton.
--
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 Zealanddavidsen@steinmetz.ge.com (William E. Davidsen Jr) (06/29/88)
In article <399@cantuar.UUCP> paul@cantuar.UUCP (P. Ashton) writes: | We are in the middle of deciding which editor to teach students next | year, and are looking at vi and emacs. We have a couple of questions | | (i) we have heard emacs is somewhat resource hungry. What experiences do | people have with students using emacs with regard to resource use | (environment GNU emacs on a Vax 11/750 running 4.3BSD, and on sun 3/50s | and 3/60s). emacs is not monolithic, there are a number of flavors and styles. Certainly GNU emacs takes a great deal of memory, if not CPU. There are other flavors available, most commonly microemacs. While it doesn't contain a LISP compiler, most people don't really need that in their editor, nor mail reading, process control, interactive jokes, or any of the other stuff in GNU. GNU has many bells and whistles, and the LISP compiler is adequate for teaching a one semister LISP course, if desired. Microemacs will run on Ultrix, BSD, SunOS, Xenix, Cray2, MS-DOS, unix-pc, etc. It provides a full set of editing functions, windows, key redefinition, and a complete macro programming language for special key definitions. Size is about 78k on VAX, 120k on PC (with all features enabled). There is a MicroGNU emacs (now called mg) which seems to have some of the features of GNU. I haven't really tried it, but it is on several of the Suns at this site, due to problems running full GNU on machines with only 8 MB of memory. | (ii) is vi available for VMS (if so what are the details)? As part of UNIX environment for VMS, from INteractive Systems and Wolongong. I have no addresses for those vendors, but we have their software on some of our VAXen at remote sites. | Please reply by email - I will post a summary. | | Paul Ashton. | | -- | 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 -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
lm@arizona.edu (Larry McVoy) (06/30/88)
In article <11418@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <399@cantuar.UUCP> paul@cantuar.UUCP (P. Ashton) writes: >| We are in the middle of deciding which editor to teach students next >| year, and are looking at vi and emacs. We have a couple of questions As a consultant I'll volunteer the following advice: don't get people used to emacs. Please. Why? Because emacs is available on "some" unix machines. Vi is available on almost all unix machines. Old habits die hard, so I think it's better to start people out with something they can stay with... -- Larry McVoy laidbak!lm@sun.com 1-800-LAI-UNIX x286
fnf@fishpond.UUCP (Fred Fish) (06/30/88)
In article <6056@megaron.arizona.edu> lm@megaron.arizona.edu (Larry McVoy) writes: >As a consultant I'll volunteer the following advice: don't get people used to >emacs. Please. Why? Because emacs is available on "some" unix machines. >Vi is available on almost all unix machines. Old habits die hard, so I think >it's better to start people out with something they can stay with... Until recently you could use almost exactly the same argument for NOT teaching vi, since vi was ONLY available on Unix systems, while some EMACS or workalike was available on almost any OS. Now there are reasonable vi clones for many of the more commonly used systems, so I don't think the "people portability" factor is quite as onesided towards EMACS as it once was. There are also enough EMACS's available in source form (GNU, microemacs, jove, scame, mg, etc) that any EMACS addict that has to work for any length of time on a given Unix system will find some way to get one installed and thus avoid having to use vi. -Fred -- # Fred Fish, 1346 West 10th Place, Tempe, AZ 85281, USA # noao!nud!fishpond!fnf (602) 921-1113
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/01/88)
In article <6056@megaron.arizona.edu> lm@megaron.arizona.edu (Larry McVoy) writes: >As a consultant I'll volunteer the following advice: don't get people used to >emacs. Please. Why? Because emacs is available on "some" unix machines. >Vi is available on almost all unix machines. Old habits die hard, so I think >it's better to start people out with something they can stay with... If "vi" weren't such a crappy editor this might be good advice. However, many users spend much of their time text-editing, so they should use the best editor available rather than suffer with inferior tools just because they are more universal. (If they really have to deal with a wide variety of UNIX systems, then it makes more sense to emphasize universality. It would also make sense in that case to provide better tools on all those systems.) I actually do use "vi" on my Sun, until I get "sam" running. (The SunTools text editor is a joke.) Given a choice between "vi" or an EMACS variant I'll choose EMACS, but those aren't the only choices.
txr98@wash08.UUCP (Timothy Reed) (07/01/88)
In article <6056@megaron.arizona.edu> lm@megaron.arizona.edu (Larry McVoy) writes: >In article <11418@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >>In article <399@cantuar.UUCP> paul@cantuar.UUCP (P. Ashton) writes: >>| We are in the middle of deciding which editor to teach students next >>| year, and are looking at vi and emacs. We have a couple of questions >As a consultant I'll volunteer the following advice: don't get people used to >emacs. Please. Why? Because emacs is available on "some" unix machines. >Vi is available on almost all unix machines. This is very true. We use an old INteractive editor called INed here (now called tenplus on NCR towers), as well as some of their email, networking and printer software, and I feel very sorry for people that learn unix skills here based on their experiences with these pretty site-specific applications - it's going to be really hard for them to deal with the rest of the unix world since they'll bring very little useful experience to their next jobs. (however, since INteractive now owns nroff and troff, maybe theirs are the true standards of tomorrow -:) ~ ~ ~ ~ "Timothy_Reed_Am_Chem_Soc" 36 lines, 1516 characters
rja@edison.GE.COM (rja) (07/01/88)
Here at work we have one version of emacs (ie; microEMACS) running on our
VMS cluster, our UNIX VAX, and also on the IBM ATs. What is nice about it
is being able to use the same editor and key binding files on all 3 systems.
Counting other emacs variants, I suspect that you can get it for almost
any machine ( I've used it on a Prime x50 and PDP-11 as well).
According to the microEMACS 3.9i manual sitting here, it is also available
for Atari ST, Amiga, and the Apple Macintosh.
For info on obtaining microemacs you can mail to : (quoting from the manual)
Daniel Lawrence
nwd@j.cc.purdue.eduaad@stpstn.UUCP (Anthony A. Datri) (07/01/88)
>As a consultant I'll volunteer the following advice: don't get people used to >emacs. Please. Why? Because emacs is available on "some" unix machines. >Vi is available on almost all unix machines. Old habits die hard, so I think >it's better to start people out with something they can stay with... Let's say I wanted to use TPU. DEC doesn't provide that on all of it's operating systems, so don't get people used to it. By your argument, they should all use TECO. IBM PC's all come with edlin, so everyone should use edlin. The original EMACS runs on most or all of the pdp-10 os's. Gosling/Unipress emacs runs on: AT&T 3B series AT&T 7300 Unix PC Amdahl Apollo Arete Compaq (Xenix) Computer Consoles (sysv) Convergent Technologies Convex Gound HP 9000/300/500/800 Heurikon IBM PC-AT (xenix) IBM RT/PC AIX and ACIS Integrated Solutions Intel 310 Intergraph InterPro Masscomp Motorola 1131/8000 NCR Tower Perkin Elmer 32xx Plexus xxxx Pyramid Sequent Silicon Graphics Sperry 5000/40/60/80 Sperry 7000/40 Sperry IT (xenix) Stride Sun Tandy 3000 (xenix) TI Business Pro (xenix) VAX (bsd,sysv,ultrix,vms) AT&T 6300, DEC Rainbow, HP-150, IBM-PC, TI-PC, and many clones (ms-dos) They're working on it for the macintosh. Emacs's also exist on DG machines, and EMACS is the standard editor for Primos, running on Primes. Microemacs runs on just about anything that has a c compiler (including my 2.9bsd pdp11), the amiga, and I don't know what else. Epsilon runs on the PC, and is essentially emacs. A system administrator that does not provide some sort of emacs on his machine is remiss in his responsibility. vi is *not* a reasonable editor. Unipress doesn't really charge that much for a real emacs for your unix machine, and if you want to be stingy and lose, you can try to run that GNU stuff, or if you're just poor you can run microemacs, which is a perfectly good editor. Sure, the better implementions of emacs have ridiculous functionality, but it's all dynamic -- you don't load it if you don't want it. As far as the executable size, sure, an emacs (other than micro) is going to be bigger than a vi, but if you've got four or five vi's going on four or five different files, and one emacs on four or five different files, it evens out. (oh yeah -- not all phones can do tone dialing -- limit the students to doing pulse dialing) -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, or my 11/34) beak is beak is not Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
hollombe@ttidca.TTI.COM (The Polymath) (07/02/88)
In article <109@fishpond.UUCP> fnf@fishpond.UUCP (Fred Fish) writes: }In article <6056@megaron.arizona.edu> lm@megaron.arizona.edu (Larry McVoy) writes: }>As a consultant I'll volunteer the following advice: don't get people used to }>emacs. ... Because emacs is available on "some" unix machines. }>Vi is available on almost all unix machines. ... }Until recently you could use almost exactly the same argument for NOT }teaching vi ... Now there are reasonable vi clones for many of the more }commonly used systems ... There are also enough EMACS's available in }source ... that any EMACS addict ... will find some way to get one }installed ... Just to add another perspective, here at The CAT Factory our official, standard editor is Rand e v19. Having learned it first I, of course, prefer it to either vi or emacs. Your mileage may vary. -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax|trwrb}!ttidca!hollombe
thad@cup.portal.com (07/02/88)
Throwing in my $.02 worth ... EMACS (and variants) is available for nearly every machine of interest (except my C64! :-) Systems I use regularly (which have EMACS and clones thereof) include: TOPS-20, VAX/VMS, VAX 4.3BSD, UNIX PC 3B1, Amiga, IBM PC, etc etc. Considering the value of MY time to ME, I cannot afford to learn a new editor on every system I need to use, or struggle with a different "mindset" of editor commands multiple times a day. Software is cheap; people are expensive; the goal is productivity. If I'm able to complete work faster 'cause I'm using a familiar editor, I then have more time to do the fun things in life.
jon@jonlab.UUCP (Jon H. LaBadie) (07/04/88)
In article <1832@stpstn.UUCP>, aad@stpstn.UUCP (Anthony A. Datri) writes: > The original EMACS runs on most or all of the pdp-10 os's. Gosling/Unipress > emacs runs on: > [ List and many more emacs variations deleted ] > > Sure, the better implementions of emacs have ridiculous functionality, but > it's all dynamic -- you don't load it if you don't want it. > The original poster solicited comments on which editor was most appropriate in an education environment, i.e. which would best serve the students need and prepare them for post-academia. I would come down strongly on the vi side of this polling. Just because emacs IS AVAILABLE for system X does not mean that on implementation Y of system X it will be there. Vi will be! Yeah, I know about older UNIX versions etc. Don't burn me on this point. As an employer, if I see that an employee (that's what the students will be trying to become) lists UNIX experience on their resume, I expect that employee to be able to work with the standard tools. If they can be more productive by using non-standard tools, wonderful. But the choice of supplying/not supplying that tool is ultimately mine. But the student/prospective employee should be prepared to work in whichever environment I supply. Vi experience does that for the student. In the converse situation (UNIX experience claimed, company system is UNIX-like but supplies emacs and not vi) the student's resume is accurate and informative. I know a ramp-up period will be needed for both system and editor familiarization. To my mind, if one claims to be able to work in the UNIX area, they should be able to use the basic, supplied tools. That is true whether you are talking about editors or shells or ???. You may prefer emacs and csh, but you better know vi and sh. The latter properly prepares students for their post-collegiate days. The same argument is valid for edlin in the MS_DOS world (did I really say that word ;-)?). You may not prefer edlin, but you should know how to use it. Jon LaBadie, Education Staff Manager, AUXCO / CBIS {att, ulysses, princeton}!jonlab!jon Usual employer disclaimers: why do you think I am writing this at 4:20 AM?
fnf@fishpond.UUCP (Fred Fish) (07/05/88)
In article <449@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: >The original poster solicited comments on which editor was most appropriate >in an education environment, i.e. which would best serve the students >need and prepare them for post-academia. > >Just because emacs IS AVAILABLE for system X does not mean that on >implementation Y of system X it will be there. Vi will be! Yeah, You can probably count on vi being available if and only if "system X" == "some modern version of Unix". What percentage of computer science graduates end up working with Unix? What percentage of ALL graduates, regardless of major, that work with computers, end up working on Unix? (No, I don't have these numbers either :-) If "system X" is not "some modern version of Unix" then I still maintain that the probability of having an EMACS-like editor available is far greater than the probability of having a VI-like editor available. Yes, graduates should probably know how to at least start up vi and perform simple editing tasks, particularly if they are in computer science. This discussion probably should continue in comp.editors. -Fred -- # Fred Fish, 1346 West 10th Place, Tempe, AZ 85281, USA # noao!nud!fishpond!fnf (602) 921-1113
rhealey@umn-d-ub.D.UMN.EDU (Rob Healey) (07/05/88)
If you take a close look at the original poster's message it seems to me that their asking for an editor that STUDENTS can use; not programmers, not system admins, STUDENTS. I've worked with STUDENTS in computer labs for 4 years. We use vi exclusively, why? <ESC>, arrow keys, i, a, x, dd, O, o, :wq The keystrokes listed above are ALL that 90% of the STUDENTS need. Most humans with a reasonable IQ can handle the above with 30 minutes or less practice. I'd hate to have to explain the concept of a meta key to an incomming freshman. STUDENTS don't need multiple windows or fancy features, just a fast way of creating text. Except for :wq and O all the above commands require the student to hit ONE key; no control, no shift, no meta, no multikey combination. When the students gain experience they can research new editors if they wish. For the non majors who have to take CS as a junk credit or to kill off lib eds the vi commands above serve just fine. Just thought I'd put things in a slightly different perspective. -Rob -- -Rob
bicker@hoqax.UUCP (The Resource, Poet of Quality) (07/05/88)
In article <2844@ttidca.TTI.COM>, hollombe@ttidca.TTI.COM (The Polymath) writes: > Just to add another perspective, here at The CAT Factory our official, > standard editor is Rand e v19. Having learned it first I, of course, > prefer it to either vi or emacs. Your mileage may vary. That is a very telling statistic. I learned vi first (well actually, I learned TECO first, but that's another story) and then learned emacs. I prefer emacs. I wonder how many people would be able to say the opposite. -- /kohn/brian.c AT&T Bell Laboratories Semantic Engineering Center The Resource, Poet of Quality ...ihnp4!hoqam!bicker (201) 949-5850 "It is useless for sheep to pass resolutions in favor of vegetarianism while wolves remain of a different opinion." - Wm. Ralph Inge, D.D.
ge@hobbit.sci.kun.nl (Ge' Weijers) (07/05/88)
In article <449@jonlab.UUCP>, jon@jonlab.UUCP (Jon H. LaBadie) writes:
# As an employer, if I see that an employee (that's what the students
# will be trying to become) lists UNIX experience on their resume, I
# expect that employee to be able to work with the standard tools. If
# they can be more productive by using non-standard tools, wonderful.
# But the choice of supplying/not supplying that tool is ultimately
# mine. But the student/prospective employee should be prepared to
# work in whichever environment I supply. Vi experience does that
# for the student.
An employee should be given the right tool for the job. It is doubtful
whether vi is the right tool. It has a very idiosyncratic user interface
(so has emacs).
Ge' Weijers (mcvax!kunivv1!hobbit!ge)
--
Ge' Weijers, Informatics dept., Nijmegen University, the Netherlands
UUCP: {uunet!,}mcvax!kunivv1!hobbit!geron@topaz.rutgers.edu (Ron Natalie) (07/06/88)
Since I graduaged college, I've worked on UNIX at a large Defense Contractor using UNIX for software quality assurance, a Government Research Laboratory doing computer science research, and now working in management of a University wide computer center for the State University. In each environment, the editor of preference was EMACS. Demonstrating a proficiency in vi shows little to me as the the candidate's qualifications and lends me to believe that the applicant is a candy-assed 3B2 luser. Even died-in-the-wool Doug Gwyn prefers using a real editor to "vi." -Ron
brister@td2cad.intel.com (James Brister) (07/06/88)
In article <449@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: . . . >The same argument is valid for edlin in the MS_DOS world (did I >really say that word ;-)?). You may not prefer edlin, but you >should know how to use it. > >Jon LaBadie, >Education Staff Manager, >AUXCO / CBIS >{att, ulysses, princeton}!jonlab!jon edlin? EDLIN????? ARE YOU SERIOUS? Let me calm down for a minute..... Few! I thought for a minute you were talking about edlin the "editor" that comes with MS-DOS. Nobody, and I mean absolutely no-bod-y I know knows eldin. You couldn't have mean't edlin, could you? 8^)) <-- double chin-grin (See: Ed Meese) James Brister brister@td2cad.intel.com ------------------------------------------------------------------------------ "These aren't opinions, these are facts..... That's why my employer doesn't believe a word I say."
mikep@ism780c.isc.com (Michael A. Petonic) (07/06/88)
In article <1633@hoqax.UUCP> bicker@hoqax.UUCP (The Resource, Poet of Quality) writes: >I learned vi first (well actually, I learned TECO first, but that's >another story) and then learned emacs. I prefer emacs. I wonder >how many people would be able to say the opposite. Hear hear. I learned VI before Emacs and used it for about 3 years before I evolved to GNU. 'Nuff said. -MikeP
wyle@solaris.UUCP (Mitchell Wyle) (07/06/88)
In article <1559@edison.GE.COM> rja@edison.GE.COM (rja) writes: >Here at work we have one version of emacs (ie; microEMACS) running on our >VMS cluster, our UNIX VAX, and also on the IBM ATs. What is nice about it >is being able to use the same editor and key binding files on all 3 systems. >Counting other emacs variants, I suspect that you can get it for almost >any machine ( I've used it on a Prime x50 and PDP-11 as well). >According to the microEMACS 3.9i manual sitting here, it is also available >for Atari ST, Amiga, and the Apple Macintosh. And it would be great if each of the vendors mentioned supported that particular delicious flavor of an admittedly great, editor microEMACS. Unfortunately, vi is supported on all of the unix boxes around here, including the crays, suns, sequent, convex, ATs, mac-IIs-A/UX, microvax-2000s, etc. Since there were lots of e-mail responses asking for 'em, here are my 11 reasons for prefering vi to emacs. Flames, other opinions, and emacs system administration help :-) are all welcome. Why Mitch (wyle@solaris.uucp) uses 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. 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 Informatik wyle%ifi.ethz.ch@relay.cs.net ETH Zentrum 8092 Zuerich, Switzerland +41 1 256-5237
jenny@libdev (Jenny Merrill) (07/06/88)
In article <1633@hoqax.UUCP> bicker@hoqax.UUCP (The Resource, Poet of Quality) writes: > >That is a very telling statistic. > >I learned vi first (well actually, I learned TECO first, but that's >another story) and then learned emacs. I prefer emacs. I wonder >how many people would be able to say the opposite. >-- >/kohn/brian.c AT&T Bell Laboratories Semantic Engineering Center Well, since you asked, I learned TECO first, then vi then emacs. I use vi almost exclusively. Emacs just has too much to remember. --- Jennifer K. Merrill (Jennifer.Merrill@dartmouth.edu) Library Computing Services Dartmouth College Hanover, NH Jennifer K. Merrill (Jennifer.Merrill@dartmouth.edu) Library Computing Services Dartmouth College
tab@mhuxu.UUCP (Tracey Baker) (07/06/88)
In <Jul.5.19.00.16.1988.26508@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) wrote: >[...] Demonstrating a proficiency in vi shows little >to me as the the candidate's qualifications and lends me to believe that >the applicant is a candy-assed 3B2 luser. Just one more thing to think about - for anyone who's going to get into system administration, knowledge of vi, ex, or ed is a *must*. When you've got a system that's sick and will barely boot single-user, guess what you use to muck around & fix things - yup, ed (unless, of course, you keep emacs in /bin). I worked with an SA once who had to call me to fix a config file when he couldn't get a system to boot becuase the only editor he knew was emacs. So even if the students are going to use emacs as their primary editor, they should at least be exposed to one of the "primitive" UNIX editors. Besides what I mentioned above, it's a good way to learn about regular expressions, which are necessary for other areas of UNIX use as well (grep, sed, etc.) - and learning them through use of an interactive editor is probably easier than learning by writing sed scripts. Personally, I do just fine with vi. I'd been using ed, ex, or vi for 6 years before I was ever exposed to emacs, and it was just too much trouble to switch (especially when I don't really need to). -- Tracey Baker {att, rutgers!moss}!mhuxu!tab or tab@mhuxu.att.com (201)582-5357 Rm. 2F-211, AT&T Bell Laboratories, 600 Mountain Ave., Murray Hill NJ 07974 Any resemblance to actual opinions, |"There ain't no cure when the rabid living or dead, is entirely coincidental. | rock dog bites..." - Split Sydney
sullivan@vsi.UUCP (Michael T Sullivan) (07/07/88)
In article <Jul.5.19.00.16.1988.26508@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: > wide computer center for the State University. In each environment, the > editor of preference was EMACS. Demonstrating a proficiency in vi shows little > to me as the the candidate's qualifications and lends me to believe that > the applicant is a candy-assed 3B2 luser. > > Even died-in-the-wool Doug Gwyn prefers using a real editor to "vi." The original posting wasn't about what editor people preferred. It was about what editor should be taught students. To work with Unix you have to know vi. Whether you end up using Emacs or Sun's editor isn't important. Emacs may be fine in your development environment, but if you're doing work for businesses and they have a problem with their system, you better know vi because they sure aren't going to have Emacs. Not everybody works in a swell development environment all the time. But then again, what do I know. I'm just a "candy-assed 3B2 luser (sic)". Not by choice, though. -- Michael Sullivan {uunet|attmail}!vsi!sullivan V-Systems, Inc. Santa Ana, CA sullivan@vsi.com ons, workstations, workstations, workstations, workstations, workstations, work
eirik@tekcrl.TEK.COM (Eirik Fuller) (07/08/88)
In article <1633@hoqax.UUCP> bicker@hoqax.UUCP (The Resource, Poet of Quality) writes: > ... > >I learned vi first (well actually, I learned TECO first, but that's >another story) and then learned emacs. I prefer emacs. I wonder >how many people would be able to say the opposite. >-- When I first started using Unix, I chose emacs for its online documentation; I don't like reading things on paper. I went over the deep end with mock lisp (this was Unipress emacs); the most useful thing I wasted my time on was mouse support that essentially made a copy/cut/paste editor out of emacs. When I got a workstation with no "real" (termcap-compatible) inverse video (where'd that mode line go?) in its terminal emulator, but with built-in vi mouse support and clumsy (at best) support for emacs mousing, I decided to learn vi. My switch in duties to user support soon thereafter made this decision yet the wiser. I went to the trouble of writing a terminal driver for emacs so it could use the unusual terminal emulator without giving up inverse video mode lines, partly because of the claims it couldn't be done. The author of the terminal emulator wound up fixing bugs in order for this to work; because it didn't comply with termcap nobody had ever used the inverse video before. So, after all that trouble, and hacking a bit on the X support in Unipress emacs to get my mouse support working right, I still never use emacs. I actually took the trouble of adding vi mouse support to xterm because I prefer vi. I've written a smalltalk terminal emulator too (it does essentially everything xterm does, including responding to the resize command), and it too has vi mouse support. I still know enough emacs to answer users' questions about it. But I never use it myself. I much prefer vi. Don't ask me for practical reasons. I don't do it because of startup time; I could leave an emacs X window running perpetually and startup time wouldn't matter. I don't do it so my environment is uniform; everything I use has Unipress emacs if I want it, and smalltalk has its own editor (though I prefer vi in a smalltalk terminal window for large files). I'm not shy about rebinding keys in emacs to cope with the brain-dead defaults. I just simply prefer the feel of vi. It's strange, but so am I. One of my coworkers watches me type vi (he's an emacser himself), and can't believe a file can be changed that fast. I'm a basically lazy person, and vi seems more efficient to me than emacs. In case it's unclear from the above, I have tried GNU emacs too. I don't like it. If I want the universe as part of my text editor, I'll use smalltalk. (If that didn't make sense, don't sweat it). Maybe you asked the wrong question. Has anybody switched from vi to emacs for practical, logical reasons? Mine are all silly, but a little detail like that won't change my mind.
darin@nova.laic.uucp (Darin Johnson) (07/08/88)
> In article <1633@hoqax.UUCP> bicker@hoqax.UUCP (The Resource, Poet of Quality) writes: >>I learned vi first (well actually, I learned TECO first, but that's >>another story) and then learned emacs. Actually, I learned neither first (UCSD-Pascal editor and EDT were the major ones). Although I became ingrained thoroughly with vi (never actually tried emacs for more than a few minutes), as soon as I ended up in the real world, I was stuck with EDT (for VMS). Of course, it would be nice if everyone ran UNIX (or even if almost everyone ran UNIX). Most editors are very disimilar to vi, and I never did learn EDT very well. Eventually TPU (extensible editor for VMS) came out and I fell in love with it. Later I started managing some UNIX systems part-time. Even though I finally got Gnu Emacs on VMS and UNIX, I still end up using TPU on VMS, and vi on UNIX. I use Emacs exclusively on my Amiga, so I am not unfamiliar with it. Even so, using three editors all the time, I don't seem to get too confused. UNIX: vi is partially ingrained, and emacs takes too long to pop up (I never got the hang of leaving it lying around, etc.) Also my terminal (the infamous vt220) doesn't have an excape or meta key handy. I do use Emacs when the occasion warrants. VMS: Emacs just takes too darn long to pull up. TPU gives me about the same power, considering that Emacs on VMS doesn't let me do all that it does on UNIX. I hop directories so much, that even if I leave Emacs running, I have to change directory whenever I reattach to Emacs. Symbolics: Emacs is all there is, 'nuff said. Amiga: Anyone who uses ed or edit instead of microEmacs, has probably never used microEmacs (or microGnuEmacs). I can even get used to meta-control-mouse-in-text-window type commands. If I were to explicitly force a STUDENT to use vi or emacs, I would probably have him use vi, just because it has a shorter ramp up time. The teaching assistants, terminal room attendants, and the person sitting next to them probably know vi also and can help the student. For a user with some experience, I would suggest emacs (which is what I suggest new UNIX users use on my system). Something between the two is what I would suggest if there were such a thing. When the students get to the real (possibly non-unix) world, this fictitious editor would be more similar to what they will encounter (such as always being in insert-mode). If Emacs is available, it will be easy to ramp up to. If vi is all that's around, it isn't that hard for a college graduate to learn. A final alternative is to start the students off on vi, but let them know that Emacs is available and encourage them to learn it later on when they can afford the time, and have the basic's of editing learned. Of course, knowing students, this is impracticle. Darin Johnson (...pyramid.arpa!leadsv!laic!darin) (...ucbvax!sun!sunncal!leadsv!laic!darin) "All aboard the DOOMED express!"
jpliler@wsmr04.arpa (John Pliler ASNC-TWS-SM-S 678-6257) (07/08/88)
tab@mhuxu.uucp (Tracey Baker) wrote: > system administration, knowledge of vi, ex, or ed is a *must*. When you've > got a system that's sick and will barely boot single-user, guess what you > use to muck around & fix things... It is very unlikely to have large editors like EMACS in your root partition. In many situations it may not even be possible to mount the other structures. A good SA should have knowledge of a standard UN*X editor such as ed to fix problems that may arise. However, I think a good working knowledge of EMACS is a must for any SA. I personally think that a good exposure to EMACS at the University level is important. EMACS has been ported to many different architectures of machines (not necessarily running UNIX). John Pliler
chris@mimsy.UUCP (Chris Torek) (07/08/88)
I use both. Daily. I also use ed and ex (less frequently). I can get by in GNU Emacs (my regular Emacs is `Torek Emacs', largely based on Unipress Emacs), WordStar, and EDT. So what? Obviously, every student should learn every editor on every system around :-) . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
lm@laidbak.UUCP (Larry McVoy) (07/09/88)
In article <747@vsi.UUCP> sullivan@vsi.UUCP (Michael T Sullivan) writes: >The original posting wasn't about what editor people preferred. It was It was a mistake. A big mistake to bring up editor wars again. I'm guilty too - I added to the fire. But please folks, I'm wearing out my 'n' key. Can't we move on to something a little more interesting and less religious? Please? -- Larry McVoy (laidbak!lm@sun.com | ...!sun!laidbak!lm | 800-LAI-UNIX x286)
ron@topaz.rutgers.edu (Ron Natalie) (07/09/88)
Hey, I've been a UNIX systems programmer for nearly ten years now. I've worked on UNIX from Version 6 to System V to nearly every possible flavor of BSD. I've worked on IBM-PC's and braindamaged Intel not-quite- finished-yet development systems. I've made quite a nice living on both my regular job and consulting. I never use vi. The only editor that I can count on working, without having to worry if terminfo/termcap is installed properly, has my terminal type in it, etc... is "ed." Some of these systems don't even have "vi." The only thing I know how to do in vi is type ":q." (actually, this is not true anymore, I spend a month last year debugging a UniPress EMACS vi emulator, so I had to learn a few vi commands in order to test it). Teach students "ed," that way they learn what regular expressions are. My wife and quite a few people around here who were taught "vi" and EMACS as their first editor have the slightest idea how to construct regular expressions...of course, nobody around here knows what the file system looks like now that they have FSCK. You know what else I don't like? Those overhead bins on airplanes. It used to be that you had to fit your carry on stuff under the seat and all you could put above your head is your jacket. Now as soon as a plane pulls up to the gate, half the plane jumps up and starts unloading their life's possessions from these stupid bins, dropping them on people and blocking the aisles. It used to be possible to get off a plane in a reasonable amount of time, but not anymore... -Ron
chpf127@ut-emx.UUCP (J. Eaton) (07/09/88)
In article <12371@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > I use both. Daily. I also use ed and ex (less frequently). I can > get by in GNU Emacs (my regular Emacs is `Torek Emacs', largely based > on Unipress Emacs), WordStar, and EDT. So what? Deletes ed and ex and add edlin (well, I've used it a litte ... I'm sorry, ok?) and microEmacs to the "I can get by in" section and you've got the editors I use/can sort of use. All have advantages/disadvantages. I personally dislike vi because I'm always doing things in the wrong mode and ending up in a mess. I also dislike emacs because there are a lot of things to remember. But I like vi for the regular expressions, and I like emacs for the more sane command structure. I actually use EDT more than either, because it's simple and fast, and I work with VM$ most of the time (unless I'm wasting time with news :-). > Obviously, every student should learn every editor on every system > around :-) . Obviously, it does have advantages. Besides, I can tell everyone that while I don't know all the editors Chris Torek does, I hope to someday. > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) J. Eaton UT Department of Chemical Engineering I have no real life, I'm living in a fantasy world of computers all the time.
sullivan@vsi.UUCP (Michael T Sullivan) (07/11/88)
In article <Jul.8.17.00.31.1988.19561@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: > > Teach students "ed," that way they learn what regular expressions > are. My wife and quite a few people around here who were taught > "vi" and EMACS as their first editor have the slightest idea how > to construct regular expressions...of course, nobody around here > knows what the file system looks like now that they have FSCK. Yeah, and why are students using video terminals? My wife and quite a few people I know don't know why delete is 0177 (ascii). If people would just learn about paper tape there'd be lots more knowledge around here. Sure, productivity may drop off, but they'd know more. Now, about those high-level languages some of you use... -- Michael Sullivan {uunet|attmail}!vsi!sullivan V-Systems, Inc. Santa Ana, CA sullivan@vsi.com ons, workstations, workstations, workstations, workstations, workstations, work
nate@mipos3.intel.com (Nate Hess) (07/12/88)
In article <2817@tekcrl.CRL.TEK.COM> eirik@tekcrl.TEK.COM (Eirik Fuller) writes: >Maybe you asked the wrong question. Has anybody switched from vi to >emacs for practical, logical reasons? Mine are all silly, but a >little detail like that won't change my mind. [BTW, I used vi for about 4 years, and then learned Emacs.] Reasons why I find vi claustrophobic and brain-dead (in no particular order): o lacks multiple-windowing feature; o lacks multiple-buffer/file capability; o provides NO on-line help; o provides NO indication of mode or status; o treats command line as dumb terminal line; o non-obvious method of defining and preserving macros; o no ability to customize features to anywhere near the extent that you can in Emacs; o NO features to handle rectangles of text; o NO incremental searching; o NO editor server mode ability; o NO file, buffer, or command completion; o NO reformatting with or without right justification and an arbitrary left fill. o NO understanding of many different programming languages, outlines, TeX, nroff, etc., etc.; o NO batch mode of operation, for performing general editing functions bundled in a script (which is written in Lisp). Hey, I was once a staunch vi user and supporter; then I gave Emacs a fair chance, and used it exclusively for a week. I was the only one in the company who was interested in learning it, and no one around me knew Emacs at the time. Within one week, I was familiar enough with Emacs to be able to do all the things I could do in vi, plus lots more. Ever after, vi has felt positively claustrophobic. Happy Editing! --woodstock -- "How did you get your mind to tilt like your hat?" ...!{decwrl|hplabs!oliveb|pur-ee|qantel|amd}!intelca!mipos3!nate <domainish> : nate@mipos3.intel.com ATT : (408) 765-4309
ddb@ns.ns.com (David Dyer-Bennet) (07/13/88)
In article <370@umn-d-ub.D.UMN.EDU>, rhealey@umn-d-ub.D.UMN.EDU (Rob Healey) writes: > [vi for student use...] > <ESC>, arrow keys, i, a, x, dd, O, o, :wq > > The keystrokes listed above are ALL that 90% of the STUDENTS need. Comparable emacs keystrokes appear to be arrow keys, ^K, ^X^S, ^X^C Sure is neat how much simpler VI is for easy tasks.... > Except for :wq > and O all the above commands require the student to hit ONE key; no > control, no shift, no meta, no multikey combination. On the other hand, they have to understand about insert mode versus command mode. Come to think of it, unless my VI is slipping, you've neglected any way to make corrections other than inserting characters, or deleting the whole line and starting over. (We're both assuming that the delete or backspace key works normally, right?) It's also easy to explain to the users that "normal" characters get inserted at current position, whereas all commands are "special" characters (and you can use only "control" characters for a minimal emacs subset for beginners). I've had to guide several non-computer users (writers) into editors. They seem to pick up Emacs several orders of magnitude faster than vi. Vi is downright user-hostile (that's the step BEYOND "user-surly" :-). Your mileage may vary. -- -- David Dyer-Bennet ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb ddb@viper.Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300
ddb@ns.ns.com (David Dyer-Bennet) (07/13/88)
In article <424@solaris.UUCP>, wyle@solaris.UUCP (Mitchell Wyle) writes: > Why Mitch (wyle@solaris.uucp) uses vi: > > 1) Availability: vi(1) is available on every unix box I touch. I don't > have to INSTALL it FIRST!! But it isn't standardly available on Primos, tops-20, tops-10, ms-dos, cpm, macintosh, or lots of other places. Emacs is available (and in one case standard) on all of the above. It's a much better choice for those not limiting themselves to one environment. > 4) Speed: vi(1) starts running faster. Not in my environment. I leave gnu emacs as a background task for the rare occasions I'm not working in a process window. On dos I do most work in the Epsilon process window, too. > 7) Management: vi(1) needs NO system management effort. *** It doesn't? Are you simply saying that the patch rate is lower? I'll certainly believe that. But I've expended no system management effort on the Gnu emacs here, the Epsilon at home, or the Mince at home, since I first installed them, so the difference can't be too great. > 8) Macros: vi(1) has a simple, powerful macro language not requiring > the user to know and love LISP. I never did figure out vi macros, but emacs keyboard macros are completely straightforward and obvious even to beginning users. > 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. The terminal-based emacs's I've used at low baud rates turn out to have support for them. I've yet to see an emacs which requires windowing, graphics, or special features. Many do, however, require the ability to clear the screen and position the cursor -- pretty common these days. > 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? It's VERY hard to argue with inertia as a reason -- but then, that's why I use emacs. It goes back to what's more widely available, and it's quite clear that emacs is the most widely available editor in the world. Obviously I have not addressed all your points. Many of them were correct. (I consider some of them essentially irrelevant, but that's another level of discussion.) -- -- David Dyer-Bennet ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb ddb@viper.Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300
nevin1@ihlpf.ATT.COM (00704a-Liber) (07/13/88)
In article <449@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: >You may >prefer emacs and csh, but you better know vi and sh. The latter >properly prepares students for their post-collegiate days. Maybe. The problem is: there is so much to vi and so little that can be found out (did you ever try to find a manual around a college campus?). For instance: how many college students, after using Unix and vi for 4 years, could tell you how to substitute ALL occurrences of the word 'foo' with the word 'bar' in a given document? Or what a lowercase 'f' does? Or how to pipe output to a command? Not very many people. If they prefer emacs, let them use it! >The same argument is valid for edlin in the MS_DOS world (did I >really say that word ;-)?). You may not prefer edlin, but you >should know how to use it. Since both vi and emacs are available for MS-DOS, there really is no point in learning how to use edlin. Always try to get the best tools for the job! -- _ __ NEVIN J. LIBER ..!att!ihlpf!nevin1 (312) 510-6194 ' ) ) You are in a little maze of twisting / / _ , __o ____ email paths, all different. / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
lee@uhccux.uhcc.hawaii.edu (Greg Lee) (07/13/88)
From article <420@ns.ns.com>, by ddb@ns.ns.com (David Dyer-Bennet): " ... " (We're both assuming that the delete or backspace key works normally, " right?) You consider normal behavior for delete to be backspace, and normal behavior for backspace to give help, right? Yours truly, a vi user.
g-rh@cca.CCA.COM (Richard Harter) (07/13/88)
In article <421@ns.ns.com> ddb@ns.ns.com (David Dyer-Bennet) writes: >In article <424@solaris.UUCP>, wyle@solaris.UUCP (Mitchell Wyle) writes: >> Why Mitch (wyle@solaris.uucp) uses vi: >> >> 1) Availability: vi(1) is available on every unix box I touch. I don't >> have to INSTALL it FIRST!! > But it isn't standardly available on Primos, tops-20, tops-10, ms-dos, >cpm, macintosh, or lots of other places. Emacs is available (and in one >case standard) on all of the above. It's a much better choice for those >not limiting themselves to one environment. Having dealt with emacs on Primos, I should like to point out that *some* implementations of emacs are very piggy on system resources. On the other hand, tops-20 emacs is quite nice that way. One of the nicest editors I have used is IBM's xedit (given the constraint of working on big blue iron.) I've even heard hard core emacs fans admit that xedit is a good editor :-). It is a big win in a time shared environment with heavy usage because most of the work is done in the terminal (327x of course). I.e. you edit the screen using terminal hardware and send the entire screen to the CPU. This is not as good as having a work station, and much better than editors which make the CPU do all of the work. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
guy@gorodish.Sun.COM (Guy Harris) (07/14/88)
The reason I don't use "vi" is that "vi" is the Roman numeral for 6, and three 6's make 666, the number of the beast. This reason is probably as good or bad as any of the other reasons for or against any particular editor that fly around the net every time somebody starts an editor war. There are people who like "vi", people who like EMACS, people who like EDT, people who like "ed", and people who like IBM 029 keypunches. Some of those people may be convinced that some other editor is better for them by some line of argument. Others won't be, because they're right - the editor they use *is* the best one for them, if for no reason other than familiarity; it's not worth the effort to learn a new editor. Your favorite feature of editor A may be of no consequence to some user of editor B. Your favorite gripe against editor B may not represent a problem to that user either. Unless 1) somebody has good ergonomic evidence showing that for a large majority of the users tested, some particular editor really *is* easier to use, 2) the users tested represent a good cross-section of the *entire* potential user population, and 3) that particular editor is *so* much better that it's worth the time that users of all other editors would spend learning it (and 4) that this editor is reasonably broadly available), few if any of these articles have much point. Can we please choke off the debate now?
ronc@cerebus.UUCP (Ronald O. Christian) (07/14/88)
In article <5270@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes: >In article <449@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: >>The same argument is valid for edlin in the MS_DOS world (did I >>really say that word ;-)?). You may not prefer edlin, but you >>should know how to use it. > >Since both vi and emacs are available for MS-DOS, there really is no point >in learning how to use edlin. Only if you always keep your vi or emacs diskette in your shirt pocket. If the machine is yours you can run any old editor, if you have to work on someone else's machine (say, proving your expertise for a job interview) you'd better be able to use the "stock" tools, because your favorite add-ons might not exist on that machine. This also applies to Unix. As Jon said, bourne shell and vi are more common in the real world than csh and emacs. I'm not saying "don't learn emacs", I *am* saying that you may be required to have a working knowledge of the "stock" tools. > Always try to get the best tools for the >job! If they're available! Ron -- Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.) {amdahl, pyramid, sun, unisoft, uunet}!cerebus!ronc Calling all Fujitsu Usenet sites! Contact cerebus!ronc or ronc@fai.com to establish uucp connection.
rhealey@umn-d-ub.D.UMN.EDU (Rob Healey) (07/14/88)
In article <420@ns.ns.com> ddb@ns.ns.com (David Dyer-Bennet) writes: >> [vi for student use...] >> <ESC>, arrow keys, i, a, x, dd, O, o, :wq >> >> The keystrokes listed above are ALL that 90% of the STUDENTS need. > Comparable emacs keystrokes appear to be > arrow keys, ^K, ^X^S, ^X^C ^^ Try getting a control-S through a network mux.... When you can't you lose the memory aid. >>Except for :wq and O all the above commands require the student to hit ONE key >>; no control, no shift, no meta, no multikey combination. > On the other hand, they have to understand about insert mode versus >command mode. Come to think of it, unless my VI is slipping, you've neglected >any way to make corrections other than inserting characters, or deleting the >whole line and starting over. I believe x was mentioned. They seem to grab onto the insert vs. "escape" modes very quickly. Also: i Insert at blinking box a Put stuff "After" blinking box x "X it out" O Put stuff "over" the blinking box The memory seems to hold the above better than ^K ^X^S etc. Quote of the year: "What's a "control" key, I don't see one." The usual beginner asks this one about 5 times per session, never ceases to amaze me... Startup time on our machines for vi is MUCH faster than emacs. GNU has a problem with arrow keys for some reason, we have 5 different terminals and only the vt100ish one's seem to work OK. I'm the one who had the chore of getting emacs to recognise the other brands and there was no easy solution. (Why?) Seems like the terminal code in GNU should be smart enough to handle this... > I've had to guide several non-computer users (writers) into editors. >They seem to pick up Emacs several orders of magnitude faster than vi. >Vi is downright user-hostile (that's the step BEYOND "user-surly" :-). >Your mileage may vary. I guess it does, I've never seen someone take longer than 30 minutes to learn basic vi. Vi is maintained by our vendor thus we, read ME, don't have to figure out how to make it jump through hoops. I guess it comes down to a religious/environmental issue. Vi has been easier for our beginer's to learn than emacs, we held seminars for both and vi seemed to be learned faster in our case. Maybe it's the student mentality or something? B^). >Your mileage may vary. What he said, -Rob -- -Rob
badri@valhalla.ee.rochester.edu (Badri Lokanathan) (07/15/88)
In article <59699@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) writes: > > Your favorite feature of editor A may be of no consequence to some user of > editor B. Your favorite gripe against editor B may not represent a problem to > that user either. > > Unless 1) somebody has good ergonomic evidence showing that for a large > majority of the users tested, some particular editor really *is* easier to use, > 2) the users tested represent a good cross-section of the *entire* potential > user population, and 3) that particular editor is *so* much better that it's > worth the time that users of all other editors would spend learning it (and 4) > that this editor is reasonably broadly available), few if any of these articles > have much point. > > Can we please choke off the debate now? Guy Harris, Chris Torek and several others have pointed out the futility of this religious war of editors. Guy has made several important points here, to which I would like to add a few. The purpose of any editor is to enter text and make modifications with relative ease. A rough measure of how good an editor is can be obtained by comparing the overhead of additional keystrokes for commands. Most editors that I have worked with have pluses and minuses here; I stick to the one that I am most comfortable with, simply because I do not think my productivity can go up in any way by switching to another editor. If my editor does not perform any special task that I want it to, I find a temporary alternative. The rudiments of most editors that are commercially available can be learnt within a day (it may take just a little longer to remember all features.) After that, a single page in shorthand notation to remind users of infrequently used features is all that is required for efficient use. By the end of a week, a regular user should remember most of the commonly used commands. My suggestion to the person who wanted a standard editor for a course: it really is not necessary. Let students try out both vi and emacs and use the one that they like. Experimentation is part of the learning process. -- "It's better to burn out {) badri@valhalla.ee.rochester.edu Than it is to rust- //\\ {ames,cmcl2,columbia,cornell, But I'll corrode ///\\\ garp,harvard,ll-xn,rutgers}! Till I turn to dust." _||_ rochester!ur-valhalla!badri
rbj@nav.icst.nbs.gov (Root Boy Jim) (07/19/88)
? From: Greg Lee <lee@uhccux.uhcc.hawaii.edu> ? >From article <420@ns.ns.com>, by ddb@ns.ns.com (David Dyer-Bennet): ? " ... ? " (We're both assuming that the delete or backspace key works normally, ? " right?) ? You consider normal behavior for delete to be backspace, and normal ? behavior for backspace to give help, right? ? Yours truly, a vi user. The ASCII definition of DEL is `rubout', i.e. delete-backward-character. The ASCII definition of BS is `backspace', a format effector that moves the carriage one space to the left. This is not the same as deleting the previous character. The standard erase character on VAXEN is `delete', and has always been, since the days when VAXEN were PDP-11's. To their credit, Berkeley changed their standard character set to be compatible (except for ^D) with DEC OS's. ^H is a mnemonic for `help', and makes as much sense as most editing commands. If you don't like the bindings, change them. Yours truly, a GNU emacs user. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement Careful with that VAX Eugene!
ddb@ns.UUCP (David Dyer-Bennet) (07/20/88)
In article <59699@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) writes: > There are people who like "vi", people who like EMACS, > people who like EDT, people who like "ed", and people who like IBM 029 > keypunches. Actually, I preferred the 026. It had a crisper key feel, and a lighter action. :-) > Can we please choke off the debate now? Sure, as long as we all stop at once. Seriously, I recognize editors as a religious position. This means I don't start conversations about them -- but it also means that, when a conversation is going on and heretical views are being discussed, I feel a need to express my own (equally heretical, to many people) views. I wouldn't want somebody to be hurt by actually believing that ridiculous posting by <.....> that suggested that <;;;;;> was a decent editor; people can get HURT using <;;;;;;>! Shutting up, sir! -- -- David Dyer-Bennet ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb ddb@viper.Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300 ----- News saved at 19 Jul 88 18:54:29 GMT In article <59699@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) writes: > There are people who like "vi", people who like EMACS, > people who like EDT, people who like "ed", and people who like IBM 029 > keypunches. Actually, I preferred the 026. It had a crisper key feel, and a lighter action. :-) > Can we please choke off the debate now? Sure, as long as we all stop at once. Seriously, I recognize editors as a religious position. This means I don't start conversations about them -- but it also means that, when a conversation is going on and heretical views are being discussed, I feel a need to express my own (equally heretical, to many people) views. I wouldn't want somebody to be hurt by actually believing that ridiculous posting by <.....> that suggested that <;;;;;> was a decent editor; people can get HURT using <;;;;;;>! Shutting up, sir! <<The Black Hole>> indeed. Nice try... -- -- David Dyer-Bennet ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb ddb@viper.Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300
PAAAAAR%CALSTATE.BITNET@cunyvm.cuny.edu (07/20/88)
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
writes
>The ASCII definition of DEL is `rubout', i.e. delete-backward-character.
Historically RUBOUT was a code that was all ones and so could be used
to 'rubout' an erroneus character on a piece of paper tape because it
was all holes, unlike NULL which was all non-holes and used for leaving
the paper tape as it was or preparing a long lead in.....
Like BEL (ring that bell) and CR (Carriage Return) much of the ASCII control
codes are Hysterically Historical:-)
By the way DEC perverted ASCII very successfully when it decided that
Device Control 3 and Device Control 1 would signal pause and restart
transmission (CTRL/S, CTRL/Q). Similarly There use of SUB (CTRL/Z) to
indicate EOF file was quite non ASCII standard, and so on.
I have/am developing a list of the various perverted forms of ASCII
control codes. Mail me the weirdest you've heard of (CTRL/P as interupt?,
CR as ine feed and vv) and I can summarise to the net.
Dick Botting
PAAAAAR@CCS.CSUSCC.CALSTATE(doc-dick)
paaaaar@calstate.bitnet
PAAAAAR%CALSTATE.BITNET@{depends on the phase of the moon}.EDU
Dept Comp Sci., CSUSB, 5500 State Univ Pkway, San Bernardino CA 92407
Disclaimer: What with my brain, my fingers, this Mac, Red Ryder,
the PDP and its software, NOS and the CSU CYBERS,
plus transmission errors, your machine, terminal,
eyes, and brain,.....
I probably didn't think what you thought you just read any way!rbj@nav.icst.nbs.gov (Root Boy Jim) (07/22/88)
? From: PAAAAAR%CALSTATE.BITNET%cunyvm.cuny.edu@brl.arpa ? (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> ? writes ? >The ASCII definition of DEL is `rubout', i.e. delete-backward-character. ? Historically RUBOUT was a code that was all ones and so could be used ? to 'rubout' an erroneus character on a piece of paper tape because it ? was all holes, unlike NULL which was all non-holes and used for leaving ? the paper tape as it was or preparing a long lead in..... I know that. However, to use DEL on paper tape, one has to manually move the tape back first. Not doing so would be merely a waste of paper. A terminal screen has no moving parts, so it does the moving for you. Also, it's character has no physical representation, and is erased rather than merely disguised and sunsequently ignored. I claim that these operations are one and the same modulo physical/electrical media considerations. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement Careful with that VAX Eugene!
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/29/88)
In article <16543@brl-adm.ARPA> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: >The ASCII definition of DEL is `rubout', i.e. delete-backward-character. Quite an imagination you have. DEL originated as an overpunch of all channels on the paper tape, to delete the character thereby overpunched -- NOT the previous one. >The standard erase character on VAXEN is `delete', and has always been, >since the days when VAXEN were PDP-11's. To their credit, Berkeley changed >their standard character set to be compatible (except for ^D) with DEC >OS's. DEC OSes certainly have made DEL perform an erase function for a long time, but UNIX is not a DEC OS and has had its own conventions. Since DEL was the default interrupt key since `way back when, it was not such a good idea for a UNIX implementation to change it. Many UNIX users do use DEL for the interrupt key (and usually BACKSPACE for the erase key, and ^U or ^X for line delete), >^H is a mnemonic for `help', and makes as much sense as most editing >commands. Funny, mine says "BACK SPACE" right on the key cap. That doesn't suggest "help" to me...