Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Hacking VIM

Posted by samzenpus on Mon Dec 10, 2007 02:32 PM
from the read-all-about-it dept.
Craig Maloney writes "Throughout the years, there have been many clones and re-implementations of the venerable vi editor. One variant of vi that emerged and stayed with us is VIM. Since its introduction, VIM has proven itself a worthy successor to the traditional vi editor. VIM has rightfully taken the place of standard vi implementations as the spiritual successor to vi, completely replacing the vi editor on many, if not all of the current Linux distributions. Many improvements have been made to VIM such as tabs, spell checking, folding, and many, many more. However many of these new enhancements may still remain hidden to anyone who isn't keeping up on the cutting edge of VIM development. Hacking VIM is a good resource for becoming more familiar with the new features of VIM and how to make them work best for you." Read below for the rest of Craig's review.
Hacking VIM is a short book, weighing in at a scant 210 pages. The book contains six chapters, and two appendices. The first chapter covers the history of VIM, and the lineage of vi clones that preceded it. Chapter 2 covers personalizing VIM. This chapter covers how to really take VIM and customize it for your own needs, from changing the fonts and colors for GVIM to personalizing the status bar, and using tabs. Chapter 3 deals with navigating better in VIM, whether it's in a singular file, or a group of files (which is especially important for several programming environments). Chapter 4 discusses the many productivity enhancements of VIM, such as templates, auto-completion, code folding, sessions, and the built in diff mode. Advanced formatting is covered in chapter 5, which has a few interesting tips on making code look better. Rounding out the book (and weighing in as the largest chapter of the book) is scripting VIM. VIM has excellent scripting capabilities, and this chapter covers them in great detail, from finding scripts to writing your own. Lastly, the Appendix covers some of the neat scripts available for VIM, such as a minesweeper game, and the obligatory Towers of Hanoi puzzle and mail client (because no software is considered done until it reads mail and news. :) )

Hacking VIM prefaces each tip with which version of VIM will work with each function. There were only a few instances where I noticed that a particular function was mis-marked as requiring a later version of VIM that actually worked with earlier versions. The book also contains good images which help demonstrate some of the more visual components of VIM, like tabs, folding, and the spell checker.

It is full of useful tips for getting the most out of VIM. The book is aimed at those who have already gained some familiarity with the VIM editor, and is by no means a tutorial for the novice user. There is clearly a bias in this book to the intermediate and advanced VIM users. Unfortunately, this is at odds with the first chapter, which starts with a history of the VIM editor. This wastes some of the space of the book, and would have been best used with more unique and different tips. Also, having some experience with VIM, I found certain tips weren't worth the trouble, and others quite confusing. The section on signs was a bit confusing, and I'm still unclear on why they're worth the trouble. There were several instances where I wondered what the productive benefit of a tip would be. On the other hand, I did find several tips invaluable. It's easy to overlook new functions in the CHANGELOGs, so I missed that newer versions of VIM had integrated spell-checking. Overall, Hacking VIM had enough good tips in it that I hadn't discovered on my own to make it worth the read.

Like most editors, VIM can induce editor fiddling sessions that result in little work being done, and Hacking VIM contains lots of fodder to make even the most ardent tweaker happy. Unless you carefully follow the mailing lists for VIM, and try every new feature as it is released, you might miss some really helpful productivity enhancers. My only wish for this book would be more focus on really productive tips, and less history about the other versions of vi that didn't survive. The book may have lots of "of course" items for the truly seasoned VIM user, but for those of us who don't keep up-to-date with the latest features, it is an excellent way to get more familiar with some of the truly great features that have been introduced in later VIM versions.

You can purchase Hacking VIM from amazon.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.
  • vimdiff (Score:5, Interesting)

    by loudmax (243935) on Monday December 10 2007, @02:43PM (#21646197) Homepage
    A few months ago I heard someone raving about the usefulness vimdiff at a Perl user group meeting. I looked into it, and it's become one of my favorite tools. In addition to the regular syntax highlighting, it highlights differences in two texts and by default folds areas that are identical. It's fantastic for programmers and also for sysadmins like me who want to compare different versions of configuration files.

    I use vim every day, but I know I'm only scratching the surface of it's capabilities. There are probably a lot of others on Slashdot who use vim all the time and would stand to gain from understanding more of what it can do. I'll definitely give this book a look.
      • Re:vimdiff (Score:5, Insightful)

        I was simply going to mod you offtopic (two points left) - but instead I decided to reply. Mostly because I'm curious.

        Your comment is the typical argument: "emacs is better."

        However, you do not go into why it's better. You don't even mention a slight reason as to why it's better. You state that "the rest of us" "use more decent tools" and "snicker [at those who don't]."

        Would you mind qualifying your statements?
        1) What is a "more decent tool"?
        2) Why is this other tool better to use?
        3) Who is "the rest of us"?
        4) Why make this statement with nothing to back it up? If your statement is 100% qualified and "correct" - why not just give a few reasons as to why?

        I really want to know why your "more decent tools" are so plainly superior that you don't even bother to qualify your statements as to why.
          • Re: (Score:3, Interesting)

            Actually I was being 100% honest in my question(s). My extent of emacs usage is at my school during the "Intro to UNIX" class - which I completed in four hours (the entire class).

            Four hours of emacs is just enough to hate it, and not nearly enough to understand it.

            Again, honest questions.
      • Re:vimdiff (Score:5, Informative)

        by jmorris42 (1458) * <jmorris@bea[ ]rg ['u.o' in gap]> on Monday December 10 2007, @06:00PM (#21648997) Homepage
        > the rest of us, who use more decent tools, can just snicker.

        I take it you are a code monkey developing mainstream apps, most of the more evolved ones are emacs folks. But admins and embedded folks are often working in diverse environments, many of which don't have emacs but any *NIX type environment will have vi. Busybox implements a vi clone. I seriously doubt you will find emacs on very many routers, access points, settop boxes, cell phones, etc.

        Since I use so many different machines it just makes sense to default to vi/vim and stick to assuming only the default behaviour. Emacs only makes sense if you mostly use a single home directory where you can have emacs customized.
  • vim is clearly the emacs of vi clones.
  • by pongo000 (97357) on Monday December 10 2007, @02:45PM (#21646215)
    I was actually thinkink about this the other day: As a long-time vim user (have you donated yet?), the one beef I've always had about customizing vim is the rather arcane and inaccessible syntax style that's used throughout vim. This coming from a long-time perl hacker might come across as somewhat disingenuous, but it's the truth: I love to hack with vim, but hate to hack on it!

    I plan on checking this out only to see if there is some light shed on the secrets behind writing a vim plugin.
  • VI SUCKS! (Score:5, Funny)

    by Seumas (6865) on Monday December 10 2007, @02:45PM (#21646221)
    Real men use emacs, bitches!

    Okay, not really -- but I thought someone should get that out of the way so we can move on.

    Besides, most people who say Vi or Emacs are the best secretly use nano/ae/pico when nobody is looking and we all know you do, too.
      • Re: (Score:3, Funny)

        The most terrifying part of that page was the brainfuck interpreter implemented in TECO. *shudder* Someday when the stars are right, Cthulhu dreaming in R'yleh will run that program and unmake the world.
  • by deweycheetham (1124655) on Monday December 10 2007, @02:51PM (#21646305)
    Most don't take the time to read the documentation http://www.eandem.co.uk/mrw/vim/usr_doc/index.html [eandem.co.uk] . One of the great thing about VI(M) is the ability to execute this in Batch Mode (i.e. Ex ). For that matter in these days of Microsoft Glory and GUI's that don't work so well, its nice to know that GNU Tools http://gnuwin32.sourceforge.net/ [sourceforge.net] are around for all those pesky OS's that fall short of Batch Processing abilities of any sort to speak of. VI(M) also operates in this area quite well.

    Nice to know it's not forgotten.
  • I use nano. It's enough for my basic needs, and doesn't depend on cryptic key sequences :)
    • Re: (Score:2, Informative)

      When I first started using *nix, I used nano too. It's got simple key combinations to do simple actions. I used it for years.

      I didn't start to use Vim until I started work at a software shop where the lead developers used it almost exclusively. I couldn't figure out why... but then they showed me how to customize parts of it. To add syntax highlighting and tabs, and to record macros (for doing the same operation on a bunch of different chunks of text). You can even enable mouse support when working in an XT
    • I use nano. It's enough for my basic needs, and doesn't depend on cryptic key sequences :)

      I used to use pico until my mentor saw it open in my terminal one day. He uninstalled it and gave me a Vim cheatsheet. I cursed his name for about a week, then grudgingly committed myself to learning Vim for a few weeks, then eventually came to thank him.

      Then he introduced me to Emacs, and I'm still cursing his name.

      C-x C-s

      • by Hatta (162192) on Monday December 10 2007, @03:49PM (#21647207) Journal
        Well there's a difference between being hard to understand and being hard to remember. VIM and nano are both easy to understand. VIM is just hard to remember. Nano gets a pass because it's got a crib right on the screen. Of course you can only fit so much on a screen, so there's only so much you can do with nano. Which approach is friendlier than the other is up to the user to decide. Personally I'll take the more powerful editor and just print out my own crib sheet.
      • Re: (Score:3, Funny)

        M-x w3-fetch http://books.slashdot.org/ [slashdot.org]
        C-s agree 100% (search for the comment I want to reply to)
        Enter (on the Reply to This link)

        C-c C-c to edit the multiline edit box

        That almost wasn't complicated enough. This post brought to you by Emacs!

        (Ok, the captcha was harder -- I had to download the MP3!)
  • Using vi (Score:5, Funny)

    by Anonymous Coward on Monday December 10 2007, @03:00PM (#21646455)
    I don't want to start a holy war here, but what is the deal with you vi fanatics? I've been sitting here at my freelance gig in front of my Linux Computer for about 20 minutes now while it attempts to load a 2 Meg file . 20 minutes. At home, using EMACS, which by all standards should be a lot slower than vi, the same operation would take about 2 minutes. If that.

    In addition, during this file transfer, Synaptic will not work. And everything else has ground to a halt. Even Firefox is straining to keep up as I type this.

    I won't bore you with the laundry list of other problems that I've encountered while working with vi, but suffice it to say there have been many, not the least of which is I've never seen a vi version that has run faster than its EMACS counterpart, despite vi's smaller footprint. My Windows 95 version of Notepad.exe runs faster than vi at times. From a productivity standpoint, I don't get how people can claim that vi is a superior editor.

    vi addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use vi over other faster, more stable editors.
    • coders vs. sysadmins (Score:5, Informative)

      by mungtor (306258) on Monday December 10 2007, @03:47PM (#21647169)
      Coders like Emacs, sysadmins like VI. VI is small, fast, and almost always there on any system you can get to boot. Emacs is feature-packed and almost and entire development environment in itself, but it is rarely in /sbin or somewhere else that it can be useful on a crashed system.

      Whether VI is good at handling 2MB files is generally irrelevant when you need to correct a typo in /etc/vfstab that's keeping one of your systems from booting. It may not be prefect, but it's better than ed.
    • Re:Using vi (Score:5, Informative)

      by Hatta (162192) on Monday December 10 2007, @03:56PM (#21647291) Journal
      LOL, best troll EVER.

      Not only is this a simple edit of the classic Mac troll [kottke.org](scroll to the bottom), but he gets modded insightful and 8 people take him seriously. Very good job sir.
  • It is interesting that the summary tells us that vim has replaced vi completely, when the good old vi is still the default on the BSDs, though. It must be because BSD is reportedly dead. :)
  • Used both... (Score:3, Informative)

    by Lodragandraoidh (639696) on Monday December 10 2007, @03:27PM (#21646847) Journal
    RSM must have a time machine tucked away at the FSF. Emacs was ahead of its time - and in many respects still is. Its 20 MB footprint is slim in comparison to other tools on the market today.
    Vi, via vim, is getting more bloated - and at some point will look enough like Emacs to make the matter moot.
  • The best vi clone (Score:5, Interesting)

    by hibiki_r (649814) on Monday December 10 2007, @03:32PM (#21646943)

    I for one would rather use emacs, but if key combinations like ctrl+alt+meta+% are beyond your manual dexterity, the best vi clone is vigor [sourceforge.net]

    A few years ago, I modified all of the system test environments at my workplace so that vi was just an alias to vigor. All of the administrators were thrilled with vigor's responses, including everyone's favorite: 'You pressed the right arrow key. Push OK to continue'. No OS can be considered mature (or senile) if Vigor isn't installed by default.

    • I for one would rather use emacs, but if key combinations like ctrl+alt+meta+% are beyond your manual dexterity, the best vi clone is vigor A few years ago, I modified all of the system test environments at my workplace so that vi was just an alias to vigor. All of the administrators were thrilled with vigor's responses, including everyone's favorite: 'You pressed the right arrow key. Push OK to continue'. No OS can be considered mature (or senile) if Vigor isn't installed by default.

      ok, this one got me

  • by lena_10326 (1100441) on Monday December 10 2007, @03:41PM (#21647073) Homepage
    I use vim because it gives me a very satisfying feeling of get in, do edit, get out. It's like sniping... if that makes sense. I also religiously use its visual editing, which is one of the best methods of selecting text I've ever seen. Plus, vim just gives better sensory satisfaction.

    That and screen is the killer combo for me.

    .vimrc

    set nohlsearch
    colo pablo
    set expandtab
    set shiftwidth=4
    set tabstop=4
  • by david.emery (127135) on Monday December 10 2007, @03:43PM (#21647103)
    If you need to edit the makefile for EMACS... :-)

    dave
  • Religion (Score:3, Funny)

    by PPH (736903) on Monday December 10 2007, @04:02PM (#21647375)
    vi is my shepherd. I shall not font.
    • Re:Vim is painful. (Score:4, Insightful)

      by Yold (473518) on Monday December 10 2007, @02:51PM (#21646307)
      I think emacs and vi are both painful at first, if you are used to a fully graphical IDE. I tried desperately to get comfortable w/ emacs, to no avail. For the hell of it, I tried out vim, and the flexibility of keyboard commands has really helped w/ my sore wrists.

      I've been using vi extensively for more than 3 months, and I am still a newbie. It seems like the kind of editor you literally have to use for years to become competent with, but if you learn the basics its pretty intuitive for editing.

      • Re: (Score:2, Funny)

        by Anonymous Coward

        What is this emacs thing you speak of ?
        Apparently it is "vile".

      • I wondered, as I read the summary, how long it would take for someone to mention Emacs in the comments. Congratulations.
        It wasn't sooner because they had to change mode, only after 16 beeps did the sentence appear.
    • You can run emacs in vi mode!
      • hmm, that just made me think of something.

        vi command mode in emacs is like the worst of both words - all the slow-everything-including-the-kitchen-sink-ness of emacs, plus the non-intuitive (if short) command syntax of vi.

        Is there an emacs command/edit mode for vi? To me, that would be the best of both worlds...
        • Re:I prefer EMACS! (Score:4, Insightful)

          by Frymaster (171343) on Monday December 10 2007, @03:24PM (#21646793) Homepage Journal
          the non-intuitive (if short) command syntax of vi.

          okay... i hear this a lot, and not just on this thread, that the vim syntax is 'non-intuitive', and i'm starting to wonder why people say that.

          i mean, most people here are users of some sort of *nix, an interface where 'resolv.conf' is missing an 'e' for no apparent reason and cp uses a capital R for recursive, but scp demands a lowercase one. even those of us who use the allegedly 'easy' windows operating system are confronted with a shut down command located under a menu labeled 'start'. and we all speak english, perhaps the least intuitive syntax yet developed, where 'slaughter' does not, for some reason, rhyme with 'laughter' and words like 'cleave' and 'table' can have two meanings which are diametrically opposed to each other.

          we are, all of us, confronted every day with systems of syntax that are grossly complex, inane and massively counterintuitive.

          so why are you all picking on vim?

          • Re:I prefer EMACS! (Score:5, Insightful)

            by Anonymous Coward on Monday December 10 2007, @03:39PM (#21647039)
            People who bitch about 'unintuitiveness' for their text editor either don't program often or switch editors every couple days.

            Intuitiveness just means that it is not something you can just "figure out." It's not free, it comes with a trade-off. Intuitivity comes if you inject long nomenclature, multiple steps, wizards, lots of graphical icons, and so on. All these things serve as a means of keeping you from having to commit anything to memory, since you are able to visually 'figure it out' from scratch each time.

            On the flip side, an editor like vi trades intuitiveness for precision and speed. Sure, you need to memorize some keys and commands, but the end result is improved speed, productivity, and precision. Like all things worth learning, there is a curve, and it is painful, but there are benefits.

            Why software engineers seem to think intuitivity is something worth striving for in their tools is beyond me, very few other engineering tools strive for intuitivity. Can you just figure out how to use AutoCAD to design a house? What about a TI calculator to perform calculus? Can you just intuitively use a slide rule? Of course not, because if these tools were designed with intuitivity in mind, and not overall effectiveness when trained properly, people would not be able to be nearly as productive with them.
            • Re: (Score:3, Insightful)

              I have no mod points to give you to pull you out of AC zero land, so I'll just respond that I totally agree.

              I can understand having simple tools for casual computer users or for learning purposes, but professional developers or admins who refuse to use something because it takes a little bit of work is disturbing. It's similar to programmers who can't type; seriously if you can't spend the 2 weeks it takes to learn how to touch type, then how much effort are you going to put into your craft?
    • by spun (1352) <loverevolutionar ... om minus painter> on Monday December 10 2007, @04:43PM (#21647995) Journal
      What good is an unnecessary war between EMACS and vi without a comment touting the merits of ed? [gnu.org]

      Ed is the standard text editor!
    • Re: (Score:2, Informative)

      by Anonymous Coward
      to have a "No, I just want vi!" mode?

      Remove your .vimrc, or make "set compatible" the first line of it. Or use -C to force compatibility mode.