Hacking VIM 308
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 | |
| 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 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.
vim syntaxt is quite arcane (Score:4, Insightful)
I plan on checking this out only to see if there is some light shed on the secrets behind writing a vim plugin.
Re:Vim is painful. (Score:4, Insightful)
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:I prefer EMACS! (Score:4, Insightful)
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:VI = Virtually Impossible (Score:3, Insightful)
Re:I prefer EMACS! (Score:5, Insightful)
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:As a linux neophyte... (Score:4, Insightful)
Re:vimdiff (Score:5, Insightful)
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:I prefer EMACS! (Score:3, Insightful)
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?
Re:Vim is painful. (Score:3, Insightful)
Re:Vim is painful. (Score:1, Insightful)
I notice there aren't too many positive comments about vim, which surprised me at first, until I realized they're getting work done while the emacs users who like their flashy bling are the kind to hang out on