Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Books Book Reviews

Hacking Vim 7.2 246

Posted by samzenpus from the read-all-about-it dept.
briancarper writes "Vim is an open-source text editor with a power and flexibility matched only by the steepness of its learning curve. As the author of this book states, 'Vim Can Do Everything' but configuring it to do so is sometimes daunting. Hacking Vim 7.2 aims to help the average Vimmer get the most out of customizing Vim, for fun and productivity." Read on for the rest of briancarper's review.
Hacking Vim 7.2
author Kim Schulz
pages 244
publisher Packt Publishing
rating 8
reviewer briancarper
ISBN 1849510504
summary Customizing and scripting Vim 7.2
Vim has an overwhelming number of features. Its built-in help system and documentation are comprehensive and easy to navigate once you know what you're looking for, but knowing where to start is sometimes very difficult. The best you can hope for in a book is a broad outline to point the way toward features that you didn't know much about. Hacking Vim 7.2 achieves this goal.

No topic is covered in nearly the depth you'll find in the official documentation (or even on the Vim Wiki), but every topic is covered in enough detail to let you know that a feature exists and to point you in the right direction to begin using it. Most helpfully, throughout the book are references to things to look up in Vim's help system, as well as links to various relevant scripts.

This is not a book for an absolute Vim beginner; some familiarity with Vim is assumed. And for a Vim fanatic, much of the material may be common knowledge for you already. But any seasoned Vimmer will tell you that there are always things to learn about this editor, and I think nearly everyone will learn something from this book. For someone who uses Vim and is looking to master it, this book is a great starting point, though you'll still need to dive into the official reference material to really cement your knowledge.

The book starts on an odd note. Chapter 1 is a history of vi and the various vi clones released over the past couple decades. This information is interesting trivia and serves to give credit to programmers who paved the road to Vim, but it doesn't really help anyone "hack Vim" in any way. The book probably could've done without this chapter.

Chapter 2 deals with customizing the overall look and feel of Vim. How and where to edit vimrc is covered, with brief attention given to cross-platform issues. It covers the basics (changing font faces and colors, customizing menus and toolbars), as well as pointing out some more obscure settings, like highlighting the cursor row and column (creating a kind of "cursor crosshair"), and using the match feature to highlight multiple search terms at once. This chapter is a good foundation for later chapters and a good introduction for anyone who has never edited their own vimrc.

Chapter 3 is about text navigation. Sadly, the book doesn't go into as much detail on movement commands as I would've liked. The ability to move around and manipulate text quickly in Normal Mode by combining counts and motions/operators is one of Vim's most unique and powerful features, but it only gets a few paragraphs here.

There are some interesting key mappings provided, for example how to move up and down between "virtual" lines when lines are soft-wrapped. Search is covered briefly, both plain text search and multi-file search via vimgrep, but there's little information about Vim's powerful regular expressions, which I thought was a shame. Marks are discussed, both normal "hidden" marks as well as visible "signs", the latter being a feature I've never used.

Chapter 4 is about "production boosters" and covers a wide variety of topics. Much of the chapter is devoted to "templates" and "snippets", which allow you to build skeletons of commonly-used source code (with fill-in-the-blanks markers) that can be re-used when editing new files. A system for using these templates is built from scratch using Vim script, providing a clever and useful example of scripting in action.

Auto-completion is covered in a lot of detail. Some custom key mappings are provided to help make "omni-completion" in Vim a bit easier to invoke. This chapter also very thoroughly covers Vim's multiple copy/paste registers and how they work. Recording and using macros, pointed out as one of Vim's more overlooked features, gets a good, lengthy example.

"Undo branching" in Vim is wonderful, but difficult to understand. Chapter 4 gives a simple, step-by-step example of why it's useful and how it works. This chapter also briefly discusses folding, vimdiff, netrw (editing files remotely via SSH and other protocols), and ctags. There's lots of good stuff in this chapter and you're almost certain to learn something useful.

Chapter 5 covers text formatting, both using built-in Vim commands and by piping text through external tools like par and tidy. A lot of space is devoted to using Vim to prettify plaintext, for example by centering titles on a line, adding ASCII-art dashes for headers and making bulleted lists. If you edit plaintext in Vim often, this is probably a great chapter, but I didn't find much use for most of it.

For programmers, the book discusses the different indentation styles available in Vim and very briefly shows how to write your own indentation functions, and how to indent and reformat blocks or whole files of code all at once. "Paste mode" also gets a passing mention. Personally I think a programmer reading this book would've benefited from much more detail about Vim's myriad indentation and text-wrapping options and how they work together, as this can be one of the most frustrating parts of Vim to configure correctly.

I had high hopes for Chapter 6 and 7, which deal with Vim scripting, but I was largely disappointed. Chapter 6 deals with scripting basics, and is essentially a beginner's language tutorial. It explains which variable types exist in Vim script, how if/then/else works, how for- and while-loops work, how function parameters operate, and so on, but anyone who knows a modern scripting language will learn these things quickly without much effort. There's also some basic information about how to write a syntax-highlighting script from scratch, but there's not really enough information to allow you write one for a real programming language.

Chapter 7 is supposed to be about "extended scripting" topics, but serves largely as a style guide. It details how to structure a script to check for compiled-in features and Vim version number. This chapter touches briefly on using SID and PLUG to namespace functions, but the explanation and example left me puzzled. How to use the debugger and how to make Vimballs are both explored, and the book points out that you can use Perl, Python and Ruby to script Vim without going into much detail or giving solid examples.

If you're looking for any advancing information on writing your own functions in Vim script, you're mostly out of luck here. Previous chapters in the book do include some useful and practical functions, but those functions are never really taken apart or explained in detail.

Finally there are two appendices, one of which lists a bunch of games you can play in Vim (again this could've been left out of the book and I wouldn't have missed it), as well as examples of using Vim as a mail, chat, and Twitter client. There's also a feature-by-feature comparison of Vim to MS Visual Studio, showing that many of Visual Studio's abilities can be provided in Vim given the proper scripts. I thought it was an interesting demonstration that Vim really can do everything, just in case the reader had any doubts at this point. The last appendix is a style guide for keeping your vimrc clean, mostly via common sense and splitting your configuration into multiple files.

Overall, stylistically the book is a bit dry and humorless, but it's easy enough to read and it gets its information across clearly. There were a few typos and editing errors, including a few rather glaring typos in some code examples, but overall the author seems extremely knowledgeable about Vim. The best parts of the book are where the author says "this was useful to me personally, so here's how I do X". This book is clearly written by someone who uses Vim all the time, and most of the information provided is practical and immediately usable.

I do feel the book should've gone into more detail in many areas. At 244 pages, the book is short and gives a rather shallow view of many of Vim's features. But the book hits all the right notes and leaves few features entirely unexplored.

I'd recommend this book to any person who uses Vim and wants to explore features they may have been missing. There's nothing in this book you won't find in Vim's built-in documentation, but this book lays everything out in an easy-to-read format, and should serve as a good starting point to customizing and mastering Vim.

You can purchase Hacking Vim 7.2 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 7.2 More

Hacking Vim 7.2

Comments Filter:

  • Short version (Score:5, Funny)

    by Anonymous Coward on Monday May 10, 2010 @02:30PM (#32159500)

    Use EMACS

  • That word... he doesn't seem to know what it means (Score:5, Interesting)

    by clone53421 ( 1310749 ) on Monday May 10, 2010 @02:34PM (#32159574) Journal

    Customizing something is not “hacking” it. Hacking something is taking it and using it to do something that it wasn’t originally designed for in a creative way that most people would never think of.

    This is the only part of the book that is illustrative of “hacking” Vim:

    Finally there are two appendices, one of which lists a bunch of games you can play in Vim (again this could've been left out of the book and I wouldn't have missed it), as well as examples of using Vim as a mail, chat, and Twitter client. There's also a feature-by-feature comparison of Vim to MS Visual Studio, showing that many of Visual Studio's abilities can be provided in Vim given the proper scripts. I thought it was an interesting demonstration that Vim really can do everything, just in case the reader had any doubts at this point.

  • Wow (Score:2, Insightful)

    by Anonymous Coward

    Vim has an overwhelming number of features. Its built-in help system and documentation are comprehensive and easy to navigate once you know what you're looking for, but knowing where to start is sometimes very difficult.

    It's really intuitive, once you get to know how to use it.

    • Re: (Score:3, Insightful)

      by Tetsujin ( 103070 )

      Vim has an overwhelming number of features. Its built-in help system and documentation are comprehensive and easy to navigate once you know what you're looking for, but knowing where to start is sometimes very difficult.

      It's really intuitive, once you get to know how to use it.

      I hate to ruin a perfectly good joke by being all serious, but, actually, that would be true of a lot of applications. (Or, perhaps, it's not accurate to call them intuitive at all - rather, they just offer enough support via documentation, etc. to help you muddle through) Anything that's hard to get started with, but offers a lot of assistance once you're up and running. I'd say Emacs fits this description to some extent - cryptic keyboard shortcuts (which are quite handy once you learn 'em) - and then t

    • Very true.

      Sounds bit stupid, but in VIM one has to learn even how to type text.

      When I started with Linux 10+ years ago, I have dedicated two weeks to each: Emacs and VIM. Everybody had recommended Emacs, but after spending two weeks with it, reading mail lists and talking to devels I still couldn't configure it to work as I wanted it to. Next came VIM and it really took me two days to learn the basics and how configure it to my liking - and start working efficiently without further digging.

      Otherwi

  • Can it help me find the holy-grail?

  • "Steep" learning curve (Score:4, Interesting)

    by Dracker ( 1323355 ) on Monday May 10, 2010 @02:47PM (#32159782)
    This is one of my pet peeves.

    A steep learning curve refers to something that is quickly learned, as the curve that represents knowledge over time would indeed be steep in that case.

    Something difficult would have a shallow learning curve, not a steep one.

    • Re:"Steep" learning curve (Score:5, Insightful)

      by Tetsujin ( 103070 ) on Monday May 10, 2010 @02:54PM (#32159890) Homepage Journal

      This is one of my pet peeves.

      A steep learning curve refers to something that is quickly learned, as the curve that represents knowledge over time would indeed be steep in that case.

      Something difficult would have a shallow learning curve, not a steep one.

      I think usually when people talk about learning curves, the horizontal axis represents knowledge and the vertical axis is your investment to acquire that knowledge.

      Is there some established convention that contradicts this?

      • Re:"Steep" learning curve (Score:5, Informative)

        by Clueless Moron ( 548336 ) on Monday May 10, 2010 @03:13PM (#32160186)

        This is one of my pet peeves.

        A steep learning curve refers to something that is quickly learned, as the curve that represents knowledge over time would indeed be steep in that case.

        Something difficult would have a shallow learning curve, not a steep one.

        I think usually when people talk about learning curves, the horizontal axis represents knowledge and the vertical axis is your investment to acquire that knowledge.

        Is there some established convention that contradicts this?

        The problem is that in mathematics, the independent variable normally goes on the X axis (horizontal). In the case of learning, "effort" is the independent variable since "knowledge acquired" depends on "effort" and not the other way around. By that model a steep learning curve is one where a little bit of effort gains you a lot of knowledge. Unfortunately this doesn't match the classic usage of the phrase.

        And that's why I don't use that phrase. Instead I say things like "python has a gentle learning curve" or "emacs has a tough learning curve"

        • Re: (Score:2)

          by lahvak ( 69490 )

          The problem is that in mathematics, the independent variable normally goes on the X axis (horizontal). In the case of learning, "effort" is the independent variable since "knowledge acquired" depends on "effort" and not the other way around.

          Hm, I disagree with that. Assuming that knowledge acquired is a one-to-one function of effort, it does not matter which of the variables is dependent and which is independent. I think more common question is going to be "how much effort do I need to acquire certain kno

      • Re:"Steep" learning curve (Score:4, Funny)

        by clone53421 ( 1310749 ) on Monday May 10, 2010 @03:16PM (#32160216) Journal

        He’s assuming that the horizontal axis is Time, which would be pretty typical for most graphs. Not for learning curves, though.

      • Yes, the convention of placing independent variables on the horizontal axis and dependent variables on the vertical axis. Though I think the expressive use of "steep" to mean "requiring effort" justifies ignoring that convention.
    • Climbing a steep mountain doesn't mean you go upwards super fast. It means that it is tiring and laborious. So rather than thinking that the curve is knowledge_rate x time. Think effort x total_knowledge.

    • You're right about the technical / original intent of the phrase, but it's clearly entered the colloquial more literally (you have a steep [ie, difficult] path ahead of you to learn).

      Think of it this way...if you have a revolutionary new product that's very easy to learn to use, would you advertise it as having a "steep learning curve" and expect people to think that's a good thing?

      This phrase, like many others (think "begging the question") due to the literal meanings of the words has a different meaning f

    • Think of the X axis as the amount of stuff you can do, and the Y axis as the amount of time/effort involved in learning. Then for VIM you end up getting something roughly like a square root graph.

    • Re: (Score:2)

      by blair1q ( 305137 )

      Wrong-o. Something with a steep learning curve is somthing that has a lot to be learned in a short period of time in order to put it into productive use.

      It's not about how easy it is to learn the stuff, it's about how much stuff there is and how much of it you need up-front.

  • Get the following volumes too: (Score:5, Funny)

    by Ancient_Hacker ( 751168 ) on Monday May 10, 2010 @02:52PM (#32159850)

    Get the followup volumes too:

    Noise cancelling algorithm design using sh. ( Shhhhhh... )

    Real-time traffic control with bash.

    Time-domain-reflectometry made easy, with sed.

    GPS satellite tracking with tr.

    Build a species database with Python. ... and many more ...

  • Case in point: I want it to show me a vertical line at 80 chars, like TextMate or GEdit. Not even GVim can do this. :-)

    • Re: (Score:2)

      by lahvak ( 69490 )

      Well, you could create a syntax rule that would highlight the 80th character on each line, or the first 80 characters, or the 81 and higher characters...

      The problem is, what is a character?

    • Case in point: I want it to show me a vertical line at 80 chars, like TextMate or GEdit. Not even GVim can do this. :-)

      My copy of vim does. It's called "the right edge of the window". That's why running an xterm in 80x24 is good.

      My main peeve with vim is when it goes into "recording mode" or whatever that nonsense is, when I try to ":q" and hit something by mistake and the screen splits. I still don't know what I did wrong. And that vim always wants to go back to the last place in the file you edited, ev

      • Re: (Score:3, Informative)

        by Clueless Moron ( 548336 )

        My main peeve with vim is when it goes into "recording mode" or whatever that nonsense is, when I try to ":q" and hit something by mistake and the screen splits. I still don't know what I did wrong. And that vim always wants to go back to the last place in the file you edited, even if you edited the file ten years ago and really want to start at the top. The only way I found around that one is to make the .viminfo file chmod 000 so it can't save status.

        Recording mode is your friend. It means you hit "q" followed by some letter. It's a macro recorder. Let's say you want to do some complicated operation on a number of lines. Type "qq" to start recording into "q" and do the commands in a generalized fashion on one line, making sure that at the end you end up with the cursor on the next line. Type "q" to stop recording. Now type "@q" to execute those commands again, and the current line should get fixed. Or type "20@q" to do it 20 times. You get the

      • Re: (Score:2)

        by Miffe ( 592354 )

        My main peeve with vim is when it goes into "recording mode" or whatever that nonsense is, when I try to ":q" and hit something by mistake and the screen splits. I still don't know what I did wrong.

        You entered q: which open the command line window.

        And that vim always wants to go back to the last place in the file you edited, even if you edited the file ten years ago and really want to start at the top. The only way I found around that one is to make the .viminfo file chmod 000 so it can't save status.

        There is a autocommand defined for this by default. Do a au! vimrcEx BufReadPost to disable it.

  • I know about 5% of VIM and that does everything I need in a text editor. I always wonder why the other 95% was created and who the heck uses it.

  • Rating inflation (Score:5, Interesting)

    by jmilne ( 121521 ) on Monday May 10, 2010 @03:36PM (#32160524)
    I read the review before I really noticed the rating. How does this book earn an 8 for a rating? The reviewer states that Chapters 1 was unnecessary, and has some harsh things to say about several other areas:

    Chapter 3 is about text navigation. Sadly, the book doesn't go into as much detail on movement commands as I would've liked.

    I had high hopes for Chapter 6 and 7, which deal with Vim scripting, but I was largely disappointed.

    If you're looking for any advancing information on writing your own functions in Vim script, you're mostly out of luck here.

    Overall, stylistically the book is a bit dry and humorless

    I do feel the book should've gone into more detail in many areas. At 244 pages, the book is short and gives a rather shallow view of many of Vim's features.

    There's nothing in this book you won't find in Vim's built-in documentation

    At best, it seems like this would earn a 5 rating.

  • Seems like just yesterday that X in the statement "'[X] Can Do Everything' but configuring it to do so is sometimes daunting." would have been Emacs. Further evidence of the decline of civilization ... what's next- "'a GUI Can Do Everything' but configuring it to do so is sometimes daunting?"

  • For example, most censors at the FCC use Vim to generate the BEEPs over forbidden words. For everything else, you there is Emacs.

  • I remember seeing a vim hack once, a few years back, where someone used the stdin/paste to make vim animate a picture of ASCII art.
    Can't find the link, though :(

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close