Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Vi IMproved -- Vim 418

Posted by timothy from the named-after-the-aliens-who-wrote-it dept.
Craig Maloney writes: "Bram Moolenaar's Vim editor has quickly become the clone of choice for users of the venerable vi editor. Unfortunately, until recently finding documentation for the features of Vim meant spending quality time with the help files that come with Vim. While the help files are very good, a manual/tutorial of the Vim editor was needed. Other vi books included scant pages about the improvements of Vim over standard vi, but Vim isn't only a slight improvement to vi. Vi IMproved -- Vim is the manual Vim users need to help them get the full benefit out of Vim." Read on for more of Craig's review of this book below.
Vi IMproved -- Vim
author Steve Oualline
pages 572
publisher New Riders
rating 7.5/10
reviewer Craig Maloney
ISBN 0735710015
summary The first and only published book covering the basic and advanced usage of Vi IMproved.

Learning to crawl

Books describing editors generally fall into two categories. The first category of books will describe a particular function (like moving through a file) with all the known ways for performing that function, ad nauseum. The second category distills the myriad of ways to perform that function into a handful of the most common or most useful ways. Vi IMproved -- Vim combines both methods with good results.

The first section of the book is entitled Basic Editing; this section introduces the reader to starting and using Vim effectively without getting too bogged down in the gory details of Vim's vi heritage. In the chapter on moving around, the author begins with two methods of movement. In the details portion, the author has the reader performing more complex movements. This is a good approach, much like learning how to walk before learning how to hop, skip, jump, and dance through your document. Unfortunately this approach makes using this book as a reference very difficult. I would read sections that I wanted to use later, only to realize I couldn't find the section again. Vi IMproved -- Vim more than makes up for this shortcoming with a generous appendix detailing the Normal Mode, Command Mode, and Visual Mode commands along with a well-designed quick-reference section.

Made to Order

One of the strengths of Vim over other vi clones is Vim's ability to be used as a regular GUI application, and not just as an xterm-enhanced application.

Vi -- IMproved Vim shows not only how to use the GUI, but also how to customize the GUI to fit the reader's preferences. A good portion of this book deals with customizing Vim to suit the reader's style through the various parameters, menus, and GUI elements. Users who like their editors as stock as possible will find themselves skipping a lot of pages in this book. However even they will be tempted to try out some of the neat functions that pop up as they flip through the pages. The author conveys a sense of exploration, inviting users to experiment and try out new things with Vim.

Errata

Unfortunately, with vi and its clones, a single letter can mean the difference between moving through the document and deleting half of it by accident. Vi IMproved -- Vim is plagued with typos and errors, making this a difficult book for newbies to get into without having the errata sheet from http://vim.sf.net handy. It's understandable why a book like this would have some errors, especially with vi and Vim's terse keyboard commands.

Conclusion

Users of Vim will no doubt be thrilled with Vi IMproved -- Vim. Having a reference outside of the help menus in the program is a godsend for any user of Vim. Unfortunately the errors in this book mar what could have been the definitive book for Vim users, but for those who are starting out with Vim, or who would like to know more about Vim, this book is the perfect starting point and reference. The book covers the 5.x series of editors, but that shouldn't be a problem for most people looking to get started with the 6.x series.

If you're using Vim, you need Vi IMproved -- Vim.

You can purchase Vi IMproved from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Vi IMproved -- Vim More

Vi IMproved -- Vim

Comments Filter:

  • They're running out of book topics (Score:3, Funny)

    by Anonymous Coward on Wednesday August 21, 2002 @10:33AM (#4111330)
    Next: ls for dummies
  • [mandatory troll about how EMACS 0wnz Vi/Vim here] :)
    --pi

  • Vim? (Score:2, Funny)

    by FortKnox ( 169099 )
    Finally!
    Something that I can use that's better than ed!!

    (sorry, it was that or some emacs crack)

  • where to get it (Score:3, Funny)

    by unformed ( 225214 ) on Wednesday August 21, 2002 @10:34AM (#4111341)
    Vi Improved [gnu.org]

  • Cleans and polishes code!! (Score:4, Funny)

    by Jon Peterson ( 1443 ) <jon@@@snowdrift...org> on Wednesday August 21, 2002 @10:38AM (#4111369) Homepage
    It's hard to take seriously a text editor named after a sink cleaning product.

    Vim [goto.com]

  • The only problem with Vim is... (Score:3, Insightful)

    by heffel ( 83440 ) <dheffelfinger@nOsPaM.ensode.net> on Wednesday August 21, 2002 @10:38AM (#4111371) Homepage Journal
    You get spoiled by it's features.

    I use Vim on my Debian box at home, but I am stuck with standard vi on the Solaris boxes at work.

    I really miss some of its features when I'm "stuck" with "vanilla" vi.

    I'm afraid if I get this book I'll miss it even more.

    Heffel
    • Install VIM for Solaris.

      It's easy enough for a VI proofed user ;-)

      Download here for example [sunfreeware.com]

      Link is for Solaris 2.8. But you'll find the same stuff for other Solaris version an www.sunfreeware.com [sunfreeware.com]too.

      (btw. emacs is here [sunfreeware.com]

      Bye egghat.
    • I use Vim on my Debian box at home, but I am stuck with standard vi on the Solaris boxes at work.

      Snap. So I downloaded Vim for SPARC/Solaris, installed it in my home directory, altered the path and aliased 'vi' to 'vim'.

      Works like a charm.

      Cheers,
      Ian

    • I can't stand 99% of what vim does, color syntax crap, typing for me, file modes, and who knows what else. So the first thing I do when I set up a new Red Hat build is to disable vim. Seems they've decided that "vi" should be aliased to "vim" instead of running /bin/vi.
      • # rm /etc/profile.d/vim.*

      When I want all that extra stuff, I'll use emacs. vi is my plain-jane minimal-patch solution for when I'm running root.

      • Just do :set compatible

        and you get all the masochistic vi feeling you need.
    • When I was a Solaris user, I had no trouble getting vim working. Download the source, ./configure, make. Then add the executable to your path.

      One trick: some Motif programs (notably Netscape) have bad palette manners and grab a lot of colors they don't even need. I would always have at least one copy of gvim running so it always had the palette colors it needed.

  • Vi and Emacs gene discovered (Score:5, Funny)

    by LM741N ( 258038 ) on Wednesday August 21, 2002 @10:39AM (#4111381)
    "Enron Biotech has discovered a gene which may explain the sharply divided preference in the hacker community between Vi and Emacs," said George Stefanscamoulus . "this may help us to utimately produce the perfect hacker". "Only we still haven't figured out which program is really the best. More R&D is needed."

    • Gene Hackman? (Score:3, Funny)

      by Riskable ( 19437 )
      The obvious answer to that R&D is to ask Gene Hackman which he prefers.

      He'll probably blow us all away and say something completely out of line. Like, "pico".

  • WTF?? (Score:3)

    by Vinson Massif ( 88315 ) on Wednesday August 21, 2002 @10:40AM (#4111390) Homepage
    A book written to guide the newbie through a prickley (powerful!!) editor and it's chock full of errors?? The whole point of purchasing on of these is to provide a leg up the learning curve.

    Sorry, no sale.

    (The authour probably uses emacs, or worse, Word.)

    • >> It's understandable why a book like this would have some errors

      No, it's not. It's called proofreading, a concept that may or may not be familiar to the Slashdot editorial staff. Books with a lot more detail than this one (I bought it months ago) are published every day without mistakes. How about going through the galleys and testing each command and example?

    • Agreed... very poor book. (Score:2, Informative)

      by Anonymous Coward
      This is the worst book. I was a VIM newbie coming from Windowz land and the book did more to hurt me than help. It is very poorly written and has so many errors that you can't trust it. Even if the errors were fixed in a second version it'd still suck. The organization of the book is just afwul, I'd hate to see code the author generates if this spagattii is what he writes. Ick. Save your cash. Look at the customer reviews at Amazon.Com, there are quite a few "excellent" reviews, but more telling are the rare awful reviews:

      *____ Disorgainzed, Haphazard explanations -- refund time, April 8, 2002
      Reviewer: Cameron from Washinton, DC
      This book is poorly structured, for example, as a newbie I tried to figure out how I could insert a file into my current buffer... simple operation, yet with this book it took me 20 minutes before I literally stumbled accross the appropriate place in the book. This book is not organized well and it hurts. Further, the author doesn't explain VI concepts well at all. The reference part is just as dis-oraganized as the rest... just try to find what you are looking for. What made me write this review is that I just wasted another 10 minutes looking for how I can have two buffers open (but not two windows) Anyway, I've given up on this book ... perhaps I can get a refund? Any other suggestions?

      *____ Too confusing and too many errors, May 19, 2001
      Reviewer: James Snyder from Mt. Holly, NJ United States
      So far I have only read up to page 118. The large number of errors I have found so far is mind-numbing. I pity the poor beginner who has to plow through these mistakes in order to try to understand the vim program. For those who already have a copy, I ask you to compare figures 2.4 and 2.5 and tell me what is the difference between the two sets of arrows. Look at figure 2.13 and find the two outright errors, the inconsistency, and the point that might be confusing to a beginner. Read the section entitled 'How to Change Last, First to First, Last' on pages 103 and 104 and find the following:
      1. The \(, \), \1, and \2 used here will not be introduced until page 213.
      2. The regular expression in figure 9.2 is labeled a 'command', while the command itself is found nowhere.
      3. The dollar sign in the regular expression is redundant.
      4. The [^,]* could be replaced with the simpler .* unless you anticipate that there would be more than one comma on a line, in which case, any command would fail.
      5. The space after the comma in the names file is not properly accounted for.
      6. Who changes last, first to first, last anyway? It should be changed to first last, with no comma.
      This nonsense appears just after the author has introduced the :substitute command. Take a breath Mr. Oualline, and teach the basics first.

      These are not isolated problems, the whole book is like this.
      My opinion is that:
      1. Mr. Oualline has too much experience with vim to remember the needs of a beginner.
      2. The artist who created the figures seems to have no experience with vim whatever.
      3. The review process at New Riders is too careless.


      ***__ Does anyone actually read the books they review???, July 23, 2001
      Reviewer: David F DelGreco (see more about me) from Fremont, CA USA
      I decided to learn Vim because I work on WinNT/2K, Linux, and Macintosh boxes. Using a single editor makes it easier to work on mulitple platforms.

      My review of this book is mixed. First, it's the only book on Vim and it contains a lot of information, so that's a plus. Also, it shed a lot of light on using the editor that, frankly, the help files did not (you can look up *ANYTHING* via ":help ", but the documentation is not very accessible to the new user). However, the typos, errors, bad grammar, and personal idiosyncracies of Mr. Oualline just have to be seen to be believed.

      You can figure out most of the errors easily enough. For example, there's a reference to the non-BUI version of Vim (I think he meant GUI)and for some reason, in the word "filename", when used as an example (e.g., "type 'vim filename'"), the "fi" is sans-serif while the rest of the example text is in bold Courier. There are, however, numerous places where the diagrams don't match the example being discussed in the text or are just plain wrong. Some of these left me wondering if I had missed something, but trying out a command in Vim quickly showed the diagram was wrong. My favorite goof is where '#' (the command to search backwards for the word under the cursor) is shown in numerous places in Appendix C (pp. 445, 449, and elsewhere) as a British money sign (e.g., "/count/ L"), where L is the pound sign. Get it? Pound sign? Obviously the person who did the Appendices and Index (and copy-editing???) was not Mr. Oualline.

      With regard to the content, I found that Mr. Oualline is very idiosyncratic. Vim is VERY flexible, using ancient Vi ways of doing things, as well as more modern ways that are easier to use. Take yanking (copying) a block of text to a register (like the clipboard). *Mouse way*: select lines, press y. *Visual way*: move cursor to top of lines to be selected, press V, select lines, press y. *Vi-ish way*: go to top of lines to be selected, press "ma" to drop a mark labeled "a", go to bottom of lines, type y'a (yank from current position to mark "a").

      If you consider these different styles (mouse, visual, or Vi-ish) to approaching the same general problem, Mr. Oualline always goes with the Vi-ish style, to the point of also showing you in many cases how to precede the command with a line range instead of using marks. Where Ctrl-Wn (open a new window) will do, we get Ctrl-W Ctrl-N (equivalent). Where Ctrl-W moves down one window, we get Ctrl-W Ctrl-J (the arrows aren't mentioned). My guess is that this is not how the majority of new users will use Vim (though it might be handy if you find yourself using Vi or Vim via telnet).

      A real barrier to learning the editor is the immense number of variations for accomplishing a given task. Multiple keystrokes to accomplish the same thing, as well as different approaches. What would be great for Vim is an attempt to break down tasks into functional groupings (movement, formatting, programmer stuff, managing buffers/windows) and choose a style (probably visual mode, which is almost interchangeable with mouseing) so you can say "here's a good way to get started." The many variations can be left as an excercise for power users. They are available in the online help, anyway.

      All in all, I learned a lot about Vim from this book. But if I hadn't been determined to do so, I would have given up. If you want to learn Vim and the online docs aren't doing it for you, buy this book. You've been warned, so just chuckle when you come across errors and general weirdness. Kudos to Mr. Oualline for writing a book, but don't give up your day job. :-) BIG raspberries to New Riders for letting this slip through without proper editing. And thanks to Bram, who put up an unofficial list of errata at www.vim.org.


    • I bought this book about a year ago [and it had already been out for a while at that point -- why are we just getting the Slashdot review now?] and at that point I was also basically a vim/vi newbie, having been a happy Pico user for many years that only ever used vi when I needed to :%s/foo/bar something.

      /me chuckles as half the slashdot readership runs away at someone admitting that he likes pico :)

      So anyway, this was my first serious exposure to the editor, and I have to say I liked what I read. I did catch some typos -- and probably would have picked up more if I was better versed in the software -- but these weren't enough to scare me away. I liked how the book was structured, with a quick dash through the major features in the opening chapters -- here & there touching on concepts that would be formally introduced later on -- and then a longer, more detailed review of that major functionality, revisiting those concepts and showing faster & easier ways to approach different tasks, as well as customizing default behavior with such things in mind. That way, functionality I'm not interested in -- sorry, I don't read or write Farsi, so that section wasn't particularly relevant for me -- can be safely skipped without leaving the feeling that you may have needed something in there.

      Maybe the book just isn't for advanced users, or jaded Unix blowhards, or what have you. But for me, as a user of intermediate incoming experience -- and, incidently, for some of my co-workers, who do seem quite proficient in Vim -- this book was just what I had been looking for. It's worth at least skimming over in ye old bookateria some time to see if maybe the reviews & errata are blown out of proportion...

  • Correct errata sheet link (Score:5, Informative)

    by rjw57 ( 532004 ) <richwareham@nOSPaM.users.sourceforge.net> on Wednesday August 21, 2002 @10:41AM (#4111404) Homepage Journal
    The errata sheet can actually be found here [moolenaar.net]. The link in the story was only Vim's home page [sf.net].

  • Why? (Score:2, Interesting)

    by broody ( 171983 )
    What does it provide that the Vim HOWTO [tldp.org] doesn't? This strikes me as useful as a 'Developers Guide to ctags'.

  • Notes from the war (Score:4, Interesting)

    by CrosseyedPainless ( 27978 ) on Wednesday August 21, 2002 @10:42AM (#4111412) Homepage
    Although I am a die-hard emacs freek, on occasion I use one of those spiffy one-handed chording "keyboards", and I must say, vi *rocks* in that case.

    Okay, that's all. Get back to your cubicles and your Nerf(tm) Mortar Launchers.
  • ... ora's [ora.com] "learning the vi editor"? it has almost 40 pages on vim, and is (as usual with ora [ora.com]) a very good book.
    • agreed. I've got the O'reilly vi book and its been just handy dandy for me. I use vim about a billion times a day (ok not a billion but you get the picture) and anything I ever need to do is pretty handily answered in o'reilly's book.

      I love vim and my heart goes out to starving africans but I'm not buying this book. the typos I've heard about here alone is enough to steer me away from it.

      also, new riders, whats their deal? has anyone read the NR's mysql book? does it not seem like a damn near verbatim copy of the mysql online documentation only sans that helpful search function?

  • vi vs emacs and such (Score:2, Insightful)

    by ACK!! ( 10229 )
    Listen most programmers I know use emacs and love it. They love the features and they are use to the interface. fine.

    Yet, I am a sysadmin at heart and when it comes to editing things on the fly. vi is everywhere. It does not matter what way-old silly box sitting in the corner that I find vi is there. Sometimes I get stuck on windows box for a second and find myself hitting the ESC key. HA!

    I do not why things have to always have to be so heated. If you know and like emacs use it otherwise set EDITOR=vi and be done with it.

    People use different tools for different tasks sometimes because one is better than the other. Sometimes it is a just a matter of personal choice. Why this is so hard to understand is beyond me.

    ________________________________________________ _
    • The vi/emacs flamewar will never end because it is so much fun.
      • Amen. I for one am a VI user, love it to death, (vim actually) but I do realize, as do most of us that neither editor is better. Better for me, better for you, better for that guy, yes, but not absolutely better. But that doesn't stop me from ribbing the emacs guys, nor they me.

  • All most people need on one page. (Score:3, Informative)

    by YoungHack ( 36385 ) on Wednesday August 21, 2002 @10:47AM (#4111459)
    I think most people will find all the VI they need to know on the Vi reference card at vh224401.truman.edu [truman.edu]

  • mg (Score:3, Interesting)

    by Frymaster ( 171343 ) on Wednesday August 21, 2002 @10:49AM (#4111476) Homepage Journal
    the day before yesterday, my friends and i were waist-deep in the old vi-vs-emacs donnybrook (you know the one). reaching and impasse, we decided to seek arbitration with our local unix celebrity [theos.com] (who manages a fairly well-know os project [openbsd.org]).

    his suggestion? mg [kingston.ac.uk] - it's apparently "like emacs" except "without the bloat".

    ... of course i'm still going to keep using vim...

    • Re:mg (Score:2)

      by ajs ( 35943 )
      mg, microemacs, pico, etc. miss the point. I'm a vi user and an emacs user. Here's the problem with the debate: it misses the fact that emacs is not a text editor any more than sendmail is a regular expression engine. Yes, sendmail's core functionality is in regular expression handling. Yes, emacs' core functionality is in text editing. But, both do a whole lot more, and when you segment out mail header munging from regexen from dns from aliases from every which other thing, you find that they don't interoperate (about as far as you can go is qmail, which is lean compared to sendmail, but still has a lot of funtionality).

      You can use mutt to read mail, vi to edit files, and any number of other programs to do source control, diff browsing, remote file management, USENET, syntax highlighting, interpreter and debugger interaction, interactive make and error finding, etc, etc, etc. Now you have to learn all of those tools, and get used to the different user interfaces.

      You may like that. I find that using emacs for mail is too painful (emacs' single largest failing is that it does EVERYTHING, but is not multi-threaded), so I use mutt or evolution. There's no harm splitting away from emacs for one function or another, but you always have those tools there.

      On the other hand, I'm a sysadmin. When I want to edit /etc/passwd on a remote box, I run vi. When I want to edit my dot-files, I run vi (actually, vim most of the time, but I don't use its extras). When I want to hack Perl code for a few hours, I use emacs for the IDE-like environment, not for the key-bindings. If I didn't like emacs' keybindings, I'd use vi's keybindings in emacs. I used to run emacs on a 33MHz 486, and before that on some ancient UNIX boxes that I will not admit to knowing anything about, so speed is not my concern when running on a 1.2GHz dual-processor Pentium++ NG 2.1 with a twist. I just want my editor to do some of the easy work while I worry about the code.

      Don't fight over emacs vs vi, E vs twm, exim vs sendmail, Debian vs Red Hat, etc until you know both tools and all of the related tools cold. When you do, you can have an intellegent discussion about which to use when. Until you do, you're no better than the chuckle-heads who said that Last Temptation of Chirst was sacreligious without going to see it first.

      • Re:mg (Score:2)

        by crush ( 19364 )
        On the other hand, I'm a sysadmin. When I want to edit /etc/passwd on a remote box, I run vi.
        I hope that you use vipw [eu.org] when you edit your /etc/passwd !

        • Re:mg (Score:2)

          by ajs ( 35943 )
          Absolutely not. First off, I think the idea of inventing a program for every major system file would be silly. Second, the idea behind vipw is locking, and vim will warn you if the file has changed (thus giving you a more CVS-style lock rather than the vipw model which is more like rcs).

          Second, anyone who edits the passwd file without making a backup gets shot. It's that simple.

  • Vim reference guide (Score:4, Interesting)

    by selmer ( 37218 ) on Wednesday August 21, 2002 @10:53AM (#4111508) Homepage
    In "the old days" (vim 5.6), you had the vim reference guide, of which you can find a copy at for example: http://www.risner.org/vim/. It was a terribly useful reference-guide but I've never heard about anybody still working on it. Does anybody know if there's effort being put into updating it to vim 6.0?

  • Vim already comes with a tutorial (Score:3)

    by Indras ( 515472 ) on Wednesday August 21, 2002 @10:55AM (#4111517)
    While the help files are very good, a manual/tutorial of the Vim editor was needed.

    Actually, it does come with one, albeit a bit primative. I just installed the latest Linux beta (Limbo [redhat.com]) on my workstation at home. I knew it came with vim, but I really had no experience using vi or vim (I'm kinda new to Linux)... so instead of buying a manual or wading through man pages, I ran the vimtutor [linuxcommand.org].

    If you want to learn the basic features, and how to navigate vi or vim, I highly recommend it.

  • The book is online for free (Score:5, Informative)

    by christo ( 329 ) <csoghoianNO@SPAMgmail.com> on Wednesday August 21, 2002 @10:55AM (#4111524) Homepage
    You can read the entire book online here [newriders.com]
    as it has been released under the OPL licence.

    Enjoy
  • Is this vi quick reference cheat sheet [colorado.edu] (Postscript file).

    Otherwise, all you really need to remember is that Ctrl+W, N opens a new window, Ctrl+W, c closes the window. "syn on" and "syn off" turn syntax highlight on and off respectively.

    All right, all right, that was just the tips I give to complete newbies, as there is a lot more to vim than this.

    vim is good. vim rules. 'nuff said.
  • Unfortunatley, according to the linked website [sourceforge.net], the book only covers up to version 5.7. That means you miss out on some useful features like code folding, some screen splitting, etc.
    • and something i use daily:

      vim -d file1 file2

      which is like sdiff but also allows you to edit both files.

      favourite (useless) vim command is:
      1GVGg?
      try it. (repeat it to undo. or just 'u')

      andy
  • For those on a budget (or cheap) New Riders has released the book here [newriders.com]

  • vi for windows (Score:2, Informative)

    by jessearriola ( 542410 )
    At work, having to deal with code without a decent editing environment (like SQLServer stored procedures editing) I missed vi but solved the problem with a free tool: winvi.
    http://www.winvi.de [winvi.de]
  • All right, a chance for everyone to make the same "jokes" all over again! I can't wait! Maybe I can Godwinate this discussion with the most famous editor advocacy post of all time. The original can be found (here [gnu.org]), I've been forced to do some reformating to get around the fscking lameness filter.
    -=-=-=-

    From: patl@athena.mit.edu (Patrick J. LoPresti)
    Subject: The True Path (long)
    Date: 11 Jul 91 03:17:31 GMT
    Newsgroups: alt.religion.emacs,alt.slack

    When I log into my Xenix system with my 110 baud teletype, both vi *and* Emacs are just too damn slow. They print useless messages like, 'C-h for help' and '"foo" File is read only'. So I use the editor that doesn't waste my VALUABLE time.

    Ed, man! !man ed

    ED(1) UNIX Programmer's Manual ED(1)

    NAME
    ed - text editor

    SYNOPSIS
    ed [ - ] [ -x ] [ name ]
    DESCRIPTION
    Ed is the standard text editor.
    ---

    Computer Scientists love ed, not just because it comes first alphabetically, but because it's the standard. Everyone else loves ed because it's ED! "Ed is the standard text editor." And ed doesn't waste space on my Timex Sinclair. Just look:
    -rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed
    -rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi
    -rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs
    Of course, on the system *I* administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!!

    "Ed is the standard text editor." Let's look at a typical novice's session with the mighty ed:

    golem$ ed

    ?
    help
    ?
    ?
    ?
    quit
    ?
    exit
    ?
    bye
    ?
    hell o?
    ?
    eat flaming death
    ?
    ^C
    ?
    ^C
    ?
    ^D
    ?

    ---
    Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity. "Ed is the standard text editor." Ed, the greatest WYGIWYG editor of all.

    ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS
    BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN SHINE AND THE BIRDS SING AND THE GRASS GREEN!!

    When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!!
    Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!! TEXT EDITOR.

    When IBM, in its ever-present omnipotence, needed to base their "edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely you jest. They chose the most karmic editor of all. The standard.

    Ed is for those who can *remember* what they are working on. If you are an idiot, you should use Emacs. If you are an Emacs, you should not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!

    -=-=-=-
    Oh, and here's another advocacy gem from Usenet:

    "My system" is technical purity incarnate and the embodiment of all that is good in the universe. "Your system" is a loose collection of hacks done by experimental gerbil subjects on amphetamines. Remember those two constants in any debate of this nature and much of what gets said will come into the proper perspective. -- John Hubbard, in c.o.l.m

    -=-=-=-
    Since I'm still fighting to get my lines long enough to satisfy the lameness filter, I might as well throw in another this old joke [thinkgeek.com] while I'm at it.
  • (Attribution at the bottom of the post)

    When I log into my Xenix system with my 110 baud teletype, both vi *and* Emacs are just too damn slow. They print useless messages like, 'C-h for help' and '"foo" File is read only'. So I use the editor that doesn't waste my VALUABLE time.

    Ed, man! !man ed

    ED(1) UNIX Programmer's Manual ED(1)

    NAME ed - text editor

    SYNOPSIS ed [ - ] [ -x ] [ name ] DESCRIPTION Ed is the standard text editor. -----

    Computer Scientists love ed, not just because it comes first alphabetically, but because it's the standard. Everyone else loves ed because it's ED!

    "Ed is the standard text editor."

    And ed doesn't waste space on my Timex Sinclair. Just look:

    -rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed -rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi -rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs

    Of course, on the system *I* administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!!

    "Ed is the standard text editor."

    Let's look at a typical novice's session with the mighty ed:

    golem> ed

    ? help ? ? ? quit ? exit ? bye ? hello? ? eat flaming death ? ^C ? ^C ? ^D ?

    --- Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.

    "Ed is the standard text editor."

    Ed, the greatest WYGIWYG editor of all.

    ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN SHINE AND THE BIRDS SING AND THE GRASS GREEN!!

    When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!

    TEXT EDITOR.

    When IBM, in its ever-present omnipotence, needed to base their "edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely you jest. They chose the most karmic editor of all. The standard.

    Ed is for those who can *remember* what they are working on. If you are an idiot, you should use Emacs. If you are an Emacs, you should not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!

    --
    From: patl@athena.mit.edu (Patrick J. LoPresti)
    Message-ID:
    Sender: news@athena.mit.edu (News system)
    Subject: The True Path (long)
    Date: 11 Jul 91 03:17:31 GMT
    Newsgroups: alt.religion.emacs,alt.slack
    Organization: Massachusetts Institute of Technology
    Lines: 95

  • There are only two kinds of people who don't like 'vi':

    1) Those who can't type
    2) Those who don't understand 'vi'

    Yes, Emacs has a programming language that theoretically gives you some advantages, but you can't beat the power of 'vi' for being able to do complex edits extremely quickly (without having to write a program).

  • The book covers the 5.x series of editors, but that shouldn't be a problem for most people looking to get started with the 6.x series.

    Well, there are enough little changes between 5 and 6 that doing anything beyond "looking to get started" is a pain. Why write a review of a book that's been out for some time now, and is due for an updated edition?

  • Silly :) (Score:2, Informative)

    by Kitsune ( 8349 )
    Of all the things geeks fight about, it's always the text editor that draws the most blood. For an outsider it must sound rather petty. ;)

    I've found vim to have extensive documentation, though sometimes, just finding the right information is incredibly difficult to do. (I just end up grep -r ing the documentation dirs)

    If you're starting out, a cheaper hard copy alternative just to get you started (since one of the major roadblocks is the initial learning curve) is the vi quick reference [oreilly.com] from O'Reilly. Nice too that it points out vanilla commands vs implementation specific ones. Information is nicely arranged too. I think I've even seen printable posters with beautifully arranged command maps.

    Myself, I only use the basic commands anyways, I don't need the full set of features. I work on so many systems that customization is not an option. And sometimes, all these extra options just get in the way. Magic indents are interesting, ability to execute perl is interesting, but I don't really need them, infact I find them annoying. (I end up undoing the formating that vim magically formats for me) For my personnal system, I usually end up remove all the xyzzy and stick with the basics.
  • Can't we just get vim for vi users and get over it? One of my biggest frustrations with vim is that I've used vi for 15 years and when things don't work right in vim (can you say YELLOW TEXT ON A WHITE BACKGROUND IS A BAD IDEA) it is not particularly obvious where to go to find how to fix it. Help files are handy dandy nifty keen, but an as an old hack I want all the information in the damn man page, 'cos I know where to find it.

    This book looks like a good step forward (at least I can search a pdf in one shot!) but it starts out telling me lots I already know how to do because it's just vi, not the improved part. Where's the single doc "here's what we improved"?

    • # in vim, do

      :set bg=dark

      # or

      :set bg=light

      # depending on whether you have a light or dark background.
      # copy that line to ~/.vimrc to retain that setting.
      # hth

  • No joe fans? (Score:4, Insightful)

    by swb ( 14022 ) on Wednesday August 21, 2002 @12:22PM (#4112192)
    I hate vi (too weird) and emacs (weird, and bloated). Well, I should say I made a run at emacs once but never bought into the lifestyle so it was just too much overhead for simple edits.

    I've instead been a longtime fan of joe. Simple, lightweight and powerful enough for more complicated jobs. AND it's user friendly.
    • Well joe is definitlely very good. Especially if you're used to Turbo Pascal (<= 4.0) like editors.


      For a long time, I've used joe for everything: homework, web design, config files, etc.


      However, when I had to use Solaris systems, I was stuck with vi (I was able to compile joe but there were at least 4 different systems and I was lazy).


      Now I see that VI is the "true way to go". Not only because you can find it everywhere (which is true for ED also), but also it enables you to work much more efficiently. Deleting, pasting, changing a bunch of lines, using regular expressions, etc makes your life happier.


      I hope one that you'll find the light too.

  • ...is that it has the worst index of any book I've bought in recent years. With this index, quickly searching for information is almost impossible unless you're searching for info that's fairly obvious to any vi user. Because of this, the book is probably a decent tutorial but it sucks as a reference.

    Much better references can be found in the ViM help documents. In fact, the documentation is better from the included help IMHO; the problem is navigating the help files is about as intuitive as using info (which I think is about the least intuitive document navigation system ever produced).

    I have learned a lot about ViM from browsing the book, though, so I can't totally trash the book. I just think there's lots of room for improvement.
  • Vim also can embed a Python interpreter (and perl too.. but... ). I have spent a little time setting up Vim to be the centerpiece of a Python IDE. If anyone is interested in my stuff send me an email. Perhaps we can exploit the built-in Python even further to make it even better. Who knows... perhaps a Python-zippy for Vim is just around the corner...

  • How do I mark a section of text (say lines 20->25) and then automatically indent them 5 tab spaces (or maybe take a tab space out of the beginning)?

    Bryan

  • A good VI tutorial (Score:3, Funny)

    by RPoet ( 20693 ) on Wednesday August 21, 2002 @01:37PM (#4112859) Journal
    I found this VI tutorial [www.dina.dk] particularly easy to follow.
  • Oh, before I start my rant, a reminder: Vim is charityware, and the charity is a very good one. If even a fraction of Vim users did the right thing, it'd make a big difference in the world. Used to be a pain to transfer, but now Bram has a PayPal account [paypal.com], so there's no excuse.

    Ok, rant time. I'm big Vim fan. Every computer I own or use (well, every working computer) has it installed. The only editor that approaches EMACS's feature set, and nowhere near the great bloatware's klunkiness or unpredictability. But.

    I'm rather disappointed that EMACS and Vi (and its clones, of which Vim is the best and mostly widely used) remain the most widely used text editors. Now each has strengths and weaknesses relative to the other, and it's no use rehashing those wars here. What's important is that both these editors are designed around constraints that are about 20 years out of date. Most especially, they were designed to be used by a text-mode terminal (very fancy ones, in the case of EMACS, very limited ones [216.92.110.6] in the case of vi) over a relatively slow connection.

    I won't comment on EMACS, since I lack the obsessiveness to be a serious user. But on vi, the big design decision was to build in a lot of modes to get around the limitations of the terminal. This allowed a lot of commands without function keys or complicated keystrokes. It also allowed the user to enter blocks of text without realtime update -- an essential feature on a 300 baud connection!

    But, in a GUI environment, modes are a Bad Thing. Yeah yeah, some of you like being able to do complicated edits without moving your hands off the keyboard to grab the mouse. But most people have an easier time if they don't have to keep a state map current in their head.

    Now Vim has impressive GUI support (platform-independent GUI support, which is the main reason I use it), but it still has all the modes of vi, plus 3 or 4 of its own. And its macro language is a kludgy extension of the simple-minded command language Bill Joy invented for the original ex/vi editor, itself a minor extension of the ed [perl.com] command language.

    Various projects have tried to do all this over using modern design principles, but the EMACS and Vi user communities are just too entrenched. If I were a better programmer, I'd try it myself, maybe using the vim engine as a basis. But probably I'd be the only user!

  • One thing that annoys me to no end is when I install the latest version and by default some new silly screwball "IMprovement" is activated.

    Like the time line numbers (:set nu) have lines under them. You have to turn that off with (hi LineNr term=bold).

    In the latest release (from RH actually) they put visual line breaks (not real newlines) in lines that are longer than the terminal is wide so that it doesn't print text in the left margin. Supposed to look nice I guess. Not only is that just a silly worthless feature but now if I select a line in X with the mouse and paste it somewhere I get stairstepping text.

    I think their stuggling for new ideas. I wish they would clean up that morass and make a nice X widget instead.

Slashdot Top Deals

Real Programmers don't eat quiche. They eat Twinkies and Szechwan food.

Close