Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Vi IMproved -- Vim

Posted by timothy on Wed Aug 21, 2002 09:30 AM
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.

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.

+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by Anonymous Coward on Wednesday August 21 2002, @09:33AM (#4111330)
    Next: ls for dummies
  • [mandatory troll about how EMACS 0wnz Vi/Vim here] :)
    --pi
  • Finally!
    Something that I can use that's better than ed!!

    (sorry, it was that or some emacs crack)
  • by unformed (225214) on Wednesday August 21 2002, @09:34AM (#4111341)
    Vi Improved [gnu.org]
  • It's hard to take seriously a text editor named after a sink cleaning product.

    Vim [goto.com]
  • 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

        • isldev1% pwd

          /home/users/imccall/bin/vim/vim55
          isldev1% du -k .
          1891 ./doc
          1051 ./syntax
          27 ./tutor
          6 ./macros/hanoi
          10 ./macros/life
          21 ./macros/maze
          7 ./macros/urm
          73 ./macros
          55 ./tools
          3945 ./bin
          7130 .

          If your sysadmins are that nasty, then you have my deepest sympathy...

          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.
              • by ffatTony (63354) on Wednesday August 21 2002, @05:28PM (#4115158)

                There is nothing about Vim that anyone here uses that isn't part of vi.

                My favorites:

                • multi-level undo
                • expandtab - I don't need messy tabs in my code
                • syntax hilighting! hooray for anything that makes my day a little less dreary.
                • thesarus and spellcheck options
                • word/line completion/duplication
                • Amazing community - they've even got trivia questions on the sf website
                • editable command line
                • browsable Command line history
                • A big plus for me is that arrow keys function correctly. You may laugh, but the version of HPUX vi I used at my old job didn't do this
                • I also like the fact they're aren't too many cntrl-X combinations
                • acceptable start up time
                • good memory footprint
                • Less buggy than real vi's I've used, e.g. it doesn't appear to have a max-line length or max file size, doesn't crash by itself and send me an annoying email message about it
                • it reminds me if a recovery file is out there for the file I'm working on
                • warns me when the file has changed due to outside sources
                • children in Uganda

                This is why I like vim, but I also like emacs. People say I'm a little weird.

          • Vim looks like someone ate fruitloops and vomited on my screen.

            That's terribly funny, and the worst part of all the vim guys make it some damned hard to disable that crap. You have to get to

            1. start vim
            2. make sure your in normal mode
            3. type :syntax off

            Those bastards. This may seem deceptively short, but those three steps with literally take years off your life. Don't even get me started about editing the damned ~/.vimrc file. I'm only 24, yet my hands haven't stopped shaking since.

  • by LM741N (258038) on Wednesday August 21 2002, @09: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."
    • 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".
      • Actually when I want to do a quickie edit I use ed, not wanting to wait for vi to load. (Which not only takes the time for vi to load, but also the time to figgure out how to set TERM on whichever incarnation of a shell I'm using, not all of which are unix)

        Emacs is great of long programming session, it does a lot of nice formating and brace matching automaticly. (I think vi can do this too, but not as nicely) vi is great for editing configuration files, quick and easy. When normal TERM variables don't exist, or the link is slow ed really shines.

  • by Vinson Massif (88315) on Wednesday August 21 2002, @09: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?
    • 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.


  • by rjw57 (532004) <richwareham.users@sourceforge@net> on Wednesday August 21 2002, @09: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)

    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 Crosseyed & Painless (27978) on Wednesday August 21 2002, @09: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.
  • 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.

    ________________________________________________ _
  • by YoungHack (36385) on Wednesday August 21 2002, @09: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, @09: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...

  • Vim reference guide (Score:4, Interesting)

    by selmer (37218) on Wednesday August 21 2002, @09: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?
  • by Indras (515472) on Wednesday August 21 2002, @09: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.
  • by christo (329) <csoghoian&gmail,com> on Wednesday August 21 2002, @09: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.
  • For those on a budget (or cheap) New Riders has released the book here [newriders.com]
  • No joe fans? (Score:4, Insightful)

    by swb (14022) <mobocracy@gmail.com> on Wednesday August 21 2002, @11:22AM (#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.
  • by RPoet (20693) on Wednesday August 21 2002, @12:37PM (#4112859) Journal
    I found this VI tutorial [www.dina.dk] particularly easy to follow.
    • With vi in command mode almost all the keys around bound a screen movement, or editing command. I can jump around an entire file, search/replace and do any number of complex and repeditive editing operations without taking my hands off the keyboard. In many cases I dont even have to take my hands off the homerow.

      Vi is a powerful, small (memory), and fast editor thats available on every unix system I have ever seen.

      The End.

    • One tremendously useful thing VIM can do that MSVC's editor can't is to use .tags files produced by ctags. Which MSVC has it's own ctags like feature which can be enabled with the "generate browse info" option, this info can not be produced if the code won't completely compile. ctags does not have that limitation, which is a significant advantage when you're trying to navigate through undocumented code that won't compile.

      Another wonderfully useful feature of VIM is that you can record useful, exacting macros with VIM, which you certainly can't do with MSVC or, in my relatively limited experiece, any other editor other than emacs. All the power of VIM's normal mode is present in its macro capability.

      Another bonus of VIM is that it can simultaneously display many different files split horizontally or vertically. While MSVC will allow you to do this, the title bars and scroll bars in all of those windows eat up so much screen space that it's not worth doing for more than two files.

      Also, the syntax highlighting in VIM is better, or at least more configurable. For example, I've been using doxygen lately. I really like the different elements of a doxygen comment to show up in different colors so that I can pick out easily when I've made a stupid mistake. For VIM, I just went to vim.sf.net, found the friendly doxygen.vim syntax highlighting fixeruper that someone had written and I was in business. With MSVC you could probably write some extension to highlight the syntax the way you wanted, but what a pain.

      In the end it comes down to using a tool that is designed for the task. VIM was designed for editing code. The MSVC editor employs the same basic editing philosophy as notepad or MS Word, which were certainly never designed for coding. Just a simple example: VIM has a set of commands which work in a line oriented way. Software is written in lines. Honestly, a good deal of what I find myself doing with code is moving a line or a group of lines around.

      Before I starting using VIM, I was the most efficient person I knew at editing code in MSVC because I had the keyboard commands down. Now that I use VIM, I really do edit code way faster, especially for any sort of repetitive task.

    • I use both at work, so if anyone knows how to do these vim things in MSVC, let me know.

      1) Repeat the last command
      2) Execute a command an arbitrary number of times
      3) Folding
      4) Non-overlapping windows of different files

      That's all I can think of right now. I've really tried getting aquainted with MSVC, since it has our project management integrated. But when I need to do non-trivial code changes, using vim always, always is easier.

      > Any Text Editor That Needs A Book is hopelessly
      > broken.

      I truly hate this philosophy of interface design. It's what gives us useless, dumbed-down GUIs and languages like COBOL. Requiring the slightest goddamned effort by the user can make everybody's life easier.
    • The editor that comes with MSVC is usable without a book. What can VI/VIM do that it can't?

      Easy: I can't run the MSVC editor from an SSH session.
      The thing is, for the MSVC editor, all the commands are "hidden" in menus you reach with the mouse, and the keyboard shortcuts associated with them. vi just has different shortcuts.

      If you don't like vi, just use a different editor. Just use what you like best, like all of us do. I don't like vi, I use joe, jed, pico or emacs. Do I complain that vi sucks? No, because it doesn't. It just doesn't fit the way I do editing.

    • by cje (33931) on Wednesday August 21 2002, @03:14PM (#4114172) Homepage
      You may see the obtuseness of VI as part of the initiation; I see it as damage and route around it.

      This is a common misconception among people who are unfamiliar with vi (that the people who use it know that it's hard to use, but use it anyway because they're stuck and the past and so that they can feel smug and superior to the Common Man who can only use Common Editors.) However, it's dead wrong.

      I use vi because it's easy to use. That's right; vi is easy to use.

      It is not, however, particularly easy to learn, and here's where the problems arise: too many people confuse ease of use with ease of learning. If you sit somebody down in front of a tool such as the MSVC++ editor, of course they will be able to learn it quicker than they would be able to learn vi, particularly if they are already familiar with concepts such as the mouse, pull-down menus, standard keyboard shortcuts, and other familiar elements of modern windowing environments.

      But does that mean that, at the end of the day, the MSVC++ editor is easier to use than vi? I don't think so. For example, if I want to delete 8 lines of text in vi, I simply type "8dd". Now, you might say "Well, all I have to do is take the mouse, highlight those eight lines, and choose Edit->Cut or press Delete or Control-C or Control-X or whatever", and you'd be right. And this may be more intuitive and familiar then pressing "8dd", but you'd have a difficult time convincing me that it's easier, and it is most certainly not faster.

      Here's the bottom line: Some vi users accuse users of other (mostly GUI) editors of being technically-challenged simpletons. Some users of other (mostly GUI) editors accuse vi users of being anachronistic elitists. Both sides are wrong. An editor is a tool; use the one that fits you the best. Personally, I'll take vi any day, but that is my opinion (and it is for this reason that I qualify my statement with "personally.")