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

 


Forgot your password?
Close
typodupeerror
×
Book Reviews Books Media

Hacking VIM 308

Posted by samzenpus 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
author Kim Schultz
pages 210
publisher Packt Publishing
rating 7/10
reviewer Craig Maloney
ISBN 978-1-847190-93-2
summary A good way to wring more productivity out of an already excellent editor
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.
This discussion has been archived. No new comments can be posted.

Hacking VIM More

Hacking VIM

Comments Filter:

  • 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: (Score:2)

      by ajs ( 35943 )

      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.

      Vim is, in many ways, a worthy "quick and dirty emacs." Of course, all of these things have existed in emacs for decades, but there are times that you don't want to write lisp to get the job done, and the terse, Unix-derived syntax of vim is a comfort.

      I still use both vim and emacs, though more and more of my work lends itself to vim these days. If you're still thinking that the difference between vim and emacs is intuitively obvious try this:

      gvim /etc/passwd
      :vsplit /etc/group
      :split /etc/services
      :set incs

  • vim is clearly the emacs of vi clones.

  • vim syntaxt is quite arcane (Score:4, Insightful)

    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.
    • (have you donated yet?)


      You first!

    • Re: (Score:2)

      by krmt ( 91422 )
      You can script vim with several languages, including perl, python, and ruby. Not many scripts are written using them, but they are available provided that your vim build does enable those options.

  • 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.

  • A very powerfull tool of the past almost forgotten (Score:3, Informative)

    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.

  • As a linux neophyte... (Score:3, Interesting)

    by Spy der Mann ( 805235 ) <spydermann.slash ... com minus distro> on Monday December 10, 2007 @02:52PM (#21646313) Homepage Journal
    I use nano. It's enough for my basic needs, and doesn't depend on cryptic key sequences :)

    • Re: (Score:2, Informative)

      by css-hack ( 1038154 )
      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
      • Just curious, how long did it take you to become proficient with vim? To the point where you felt totally comfortable using it instead of nano, etc.?

        • Re: (Score:2)

          by Sancho ( 17056 )
          It shouldn't take long, but it depends upon how many of nano's features you use. If you don't use many advanced features, it should be dead simple. The hardest thing to learn will be dealing with the modes (insert and command.)

          Honestly, I think the best way to do it is just to dive in. Get a quick reference so that you can undo anything you didn't mean to do and just go for it. Remember that to exit, you need to be in command mode (ctrl-c or escape) and then :q (or :wq if you want to save and quit.) Wi
    • I use kwrite. It drives my advisor, who uses vi and grew up on punch cards, batty ... but when you can use it (i.e. not over ssh) it's great and simple.

    • Re:As a linux neophyte... (Score:4, Funny)

      by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Monday December 10, 2007 @04:08PM (#21647471) Homepage Journal

      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

    • The difference between Nano and Vim is that the latter can grow past your "basic needs". I mean, I've known a few programmers who use Nano, and the fact continues to baffle me, whereas Vim is an excellent general text editor, as well as being superbly designed for coding and other more heavy duty editing tasks.

      My overworked hands also enjoy the fact that Vim doesn't require me to chord (aside for a few operations, such as window splitting and navigation). It's actually the main reason I switched away from

  • 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.

    • Re: (Score:2)

      by uarch ( 637449 )

      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 a

    • Re: (Score:2)

      by argent ( 18001 )
      What version of vi are you talking about?

      vi, nvi, vim, elvis, stevie, ...?

      You're talking about a problem with some particular implementation or installation.
    • Gotta say I regularly open log files up to 2 gigs in vim. It isn't amazingly quick, and I should probably use less or something, but its very tolerable. For normal sized files, it is really fast.

      My main development editor is Eclipse, but vim is ace for everything else - and invaluable when you're ssh'ed into somewhere. It was a real shock for me recently to visit a site with Solaris 8, no vim, just the slowlaris vi. Nothing works properly! It just beeps at you.
      • This is really a YMMV thing. Here my vim just hung for about 5-7 seconds to load a 108M log file. And that's with the LargeFile plugin with threshold set to 30M. -R makes it somewhat faster, but not substantially.

    • 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.

      • 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.

        ...until that error is keeping you from mounting /usr or /usr/share, thus make termcaps unavailable, thus keeping you from running anything curses-like.

        The good news is that if you can use vi, you can probably get around OK in ed (just pretend you're typing everything at a ":" prompt and you're 90% of the way there). The bad news is that when you need it, you'll be in the worst possible mood to want to learn it.

        Not that I'm defending ed particularly! I'd personally rather use sed and hope for the be

      • Re: (Score:2)

        by ardor ( 673957 )
        Well, I code for a living. I usually use vim.
        So, am I a walking oxymoron now? That would be so cool.

      • Re: (Score:2)

        by Trogre ( 513942 )
        Last I heard ed was in the space time continuum. No word on prefect's current whereabouts.

    • 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. :)
  • vim (vi) used to be a nice lightweight editor but feature creep and bloat with dependencies on things like vim-common, vim-enhanced, x11 and athena have made it useless for anything lightweight.

    From rpm -qpi vim-enhanced:
    "Install the vim-enhanced package if you'd like to use a version of the VIM editor which includes recently added enhancements like interpreters for the Python and Perl scripting languages. You'll also
    need to install the vim-common package."

    From rpm -qpi vim-common:
    "If you are installing v

    • feature creep and bloat with dependencies on things like vim-common, vim-enhanced, x11 and athena have made it useless for anything lightweight.

      So don't install those dependencies, genius.

      I don't mean to be a jerk, but honestly, you're complaining about the mere existence of optional files?

    • Ubuntu, as of 7.10, ships with only vim-common, which is the bare minimum, lightweight text model editor. One would have to take extra steps to install the rest of the "bloat". So I don't see how this is something worth complaining about.


      Besides, what's to prevent you from rolling your own build?

  • 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.

    • 20mb? (Score:2)

      by hawk ( 1151 )
      Just 20mb for emacs? What is that, the PDP-11 version? :)

      hawk
    • Except that Vim continues to start up lightening fast, unlike Emacs... in fact, before I switched to Vim full time, I found myself consistently using it for small edits because firing up an Emacs instance took so friggin' long.

      Put another way: RAM is cheap. My time and patience aren't.
      • True, if you completely restart emacs for each edit. What I do when I log in is start emacs in the background with the server on, and then use emacsclient as my editor. Connects lightning fast, and has the added benefit of dealing easily with multiple files in different buffers (as opposed to in different emacs processes).

    • Re: (Score:2)

      by dbIII ( 701233 )
      RSM wrote it as macros for an earlier text editor. Other people wrote emacs as an application coded in C so you can't blame him for the memory footprint. He had plenty of other things to do instead - hence the long delay after the emacs fork when he found a new developer and got them up to speed.

  • 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 [sourceforge.net]

      If C-A-% is beyond your manual dexterity (what's C-A-M-%?) I'd recommend M-x replace-regexp... M-x commands are handy that way, and this approach is also somewhat helpful if you can't remember the shortcut key for a command but you maybe have a guess of what the command might be called...

    • The emacs commands killed my wrists after about 8 years, which are back to OK after about the same with just vim. And, quick startup is a bonus ;)

      Eivind.

    • 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

  • I don't use vim for the fancy features.... (Score:3, Interesting)

    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

  • VIM is useful... (Score:5, Funny)

    by david.emery ( 127135 ) on Monday December 10, 2007 @03:43PM (#21647103)
    If you need to edit the makefile for EMACS... :-)

    dave

  • Shell support (Score:2, Interesting)

    by c0nst ( 655115 )
    As a long time Vim user my main gripe is lack of good, built-in shell support. There's a patch at http://www.wana.at/vimshell/ [www.wana.at] for creating a term emulator window inside Vim. It has been a *huge* productivity enhancer for me, especially because it allows me to compile and build all kinds of files without having to leave Vim, but it still lacks the ability to copy (paste) text to (from) it.
  • ``VIM has rightfully taken the place of standard vi implementations as the spiritual successor to vi''

    Err, no, not for me. For me, the beauty of vi is that it is light. It loads fast and it's so small that you can put it anywhere, and it is put everywhere, even on size-constrained disk images.

    VIM, however, isn't small and doesn't load fast. It's not in the same niche as vi. It's in the niche where you can get pretty much any editor you want. And, frankly, I think vi and its offspring have a horrible user in
    • VIM, however, isn't small and doesn't load fast.

      Good lord, what are you running Vim on that it doesn't load instantly? I mean, sure, if it's a 66 Mhz embedded computer, Vim is probably a bit too much. But on any modern PC, it should load instantly.

      As for the rest, those are nothing more than religious arguments.
    • I agree that vim isn't really light anymore, however a lot depends on how it was compiled.

      Most Linux distros install a very minimal version by default. When you want more, there's a -common, -x11 or even -enhanced version available.

      Myself, I don't really care about footprint since it's an editor and not a daemon. And it's still too fast for me.

  • Religion (Score:3, Funny)

    by PPH ( 736903 ) on Monday December 10, 2007 @04:02PM (#21647375)
    vi is my shepherd. I shall not font.
  • I personally prefer NI labview, but that's just me. no open source equivalent 'there' yet. :)
  • So the book isn't really about hacking vim. It's about using vim, which is a difference.

    My favorite VIM hack was when I added a command that would tie in with search, and fold down all the areas that aren't within 3 lines of the searched term. So if you're going to change the name of a variable, you just search for the name of the variable ("/variable_name") and then all the sections of code that don't contain it magically fold away, and you can flip through it real fast making the name changes. This is esp

    • Re: (Score:2)

      by cymen ( 8178 )
      That sounds kick ass. Did you ever make it into a vimscript because I'd be loading that one up to try.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close