Damn, I've been using vim for almost a decade and didn't realize that /<term> worked as a movement so you can do things like <i>y2/foo</i> and yank to the second occurrence of “foo” (to use the example from the tutorial).<p>That's why I scan every beginner vim tutorial that comes across hn. I always learn <i>something</i>
Here's a Vim trick I only figured out fairly recently. Everybody knows that % jumps between a bracket, brace or parenthesis and its matched pair, but what happens if you hit % while the cursor isn't on such a character? Turns out, it searches forward until it finds such a character, then jumps to its matched pair.<p>So for example, let's say you had a nested function invocation that was getting long and unwieldy and you wanted to break it out onto its own line:<p><pre><code> foo = makeFoo(
globalConfig.getParam(
"FooSize",
int,
default="37",
)
)
</code></pre>
If you put the cursor on the 'g' at the beginning of 'globalConfig' and press "d%", it will cut the function name and all the parameters in one action.
Nice tutorial—better than many.<p>However, these kind of tutorials always fail to mention the number one way to learn Vim:<p><pre><code> vimtutor
</code></pre>
and<p><pre><code> :h usr_02.txt
</code></pre>
Those two (and successive pages in the user manual) will teach you practically everything about Vim—<i>and they're included right in Vim</i>.
Actually "cw" doesn't change the current word.. it changes where the cursor is to the end of the word. Something I tend to use <i>a lot</i> is: (| is the cursor)<p><pre><code> ciw (Really change the current word. "Fo|o Bar" -> "| Bar"
ci" (Change in between ": "Test 12|34" -> "|"
da" (Delete in between " AND the "": a"Test 12|34"b -> ab
</code></pre>
Also, plugins are extremely important. For instance, one of my favorite makes the "w" smarter for day to day programming word. (I mapped it to ,w) For example:<p><pre><code> "pac|kageManager" ci,w "|Manager"
"pac|kage_manager" ci,w "|_manager"</code></pre>
Don't do what this guy says! Or at least don't stay in phase 1 for longer than a day. I've had used vim for a few years as a pico replacement, whenever I was on a remote computer on ssh. I picked up some really bad habit, like staying in insert mode all the time and using the arrow, home and end keys. I actually had to deactivate the arrow keys in my vimrc.<p>I would recommend going thought the tutorial, that comes with vim (vimtutor command) and after that reading those articles:<p><a href="http://www.moolenaar.net/habits.html" rel="nofollow">http://www.moolenaar.net/habits.html</a><p><a href="http://www.viemu.com/a-why-vi-vim.html" rel="nofollow">http://www.viemu.com/a-why-vi-vim.html</a>
This is an _amazing_ collection once you've gone past the beginner's stage:<p><a href="http://www.rayninfo.co.uk/vimtips.html" rel="nofollow">http://www.rayninfo.co.uk/vimtips.html</a><p>For some great plugins, check <a href="http://stevelosh.com/blog/2010/09/coming-home-to-vim/" rel="nofollow">http://stevelosh.com/blog/2010/09/coming-home-to-vim/</a>
Great post. I like the way author splits the big problem into smaller ones and reduce the learning curve by different stages. When I recommend vim to my friends, they are usually frightened by the OReilly's thick vi/vim book and most people cannot "survive" in vim before they give up.
My problem with using Vim, and the source of my hesitation to learn it more, is that I'm a fairly haphazard typist. I type fast, but messily. I've never really been able to clean it up. I'm just naturally a little clumsy.<p>In my IDE, this is never, ever a problem. Most of the dangerous commands require I go to the mouse, so I can't simply blaze through them on the keyboard. Anything I mess up at the keyboard, I can always undo with backspace or a cntl+z. Furthermore, there is visual confirmation of exactly what each command I entered is doing and a chance to cancel it if it's going to do stuff I don't want.<p>In Vim, this isn't the case. I can be blazing along on the keyboard, attempt to enter a command, screw it up and enter not just one, but a whole sequence of incorrect commands. These commands could be very problematic -- doing things that are hard to undo. And it can be very difficult for me, as a Vim novice especially, to figure out exactly what I screwed up and how to undo it.<p>I know some of that may be remedied with more knowledge. I'm sure there's some way to view a detailed command history, and I know it has an undo. But I still feel as if, for myself at least, the danger of keyboard mashing screw ups completely counteracts any gains in productivity I'd make. And given that I wouldn't really gain anything by using Vim, I prefer the comfort of my visually based IDE.<p>Aside from which, I'm really fond of the way Eclipse's windows are dockable and movable and I make frequent use of that feature. Interrupting processes or juggling multiple terminal windows just isn't the same.
This post on SO has some nice bits in it : <a href="http://stackoverflow.com/questions/726894/what-are-the-dark-corners-of-vim-your-mom-never-told-you-about" rel="nofollow">http://stackoverflow.com/questions/726894/what-are-the-dark-...</a><p>"imap jj <esc>" being my favourite.
One thing I would love to see—and which I can only assume exists—is a guide like this, tailored to writing prose rather than code. This article maintains certain assumptions that are held by nearly every other guide, like <i>'You are always in normal mode, and only enter insert mode for short bursts of typing text, after which you press <Esc> to go to normal mode.'</i> Which is true and useful for coding, but slightly less so for prose—not entirely less so, and it's still a good idea to get in the habit of busting out of insert mode when you've finished whatever thought you're writing down, but the lines between thinking, composing and editing are blurrier than in prose.<p>Nevertheless vi controls can be pretty semantic, and lend themselves pretty effectively to working with words, clauses, sentences, and paragraphs. On the other hand, using search for mid-paragraph navigation is an order of magnitude less efficient in prose, when you're so much more likely to have symbols and words doing totally different things in many places in your text.
Everyone uses vim in their own way, you should learn how to use vim for the style that suits how you work. Only learn what you need to learn, you can't learn everything. No one knows all of vim; if you say that you do, you are a liar.
Nicely illustrated tutorial, well done.<p>One thing to note though: Y and yy are not shortcuts to 0y$ -- the latter does not yank the line ending. I use it to insert one line into another, but find splitting and joining lines to be cumbersome.
When I learned to use vim years ago, one interesting observation was that the biggest thing to learn in vim is efficient navigation.<p>i.e. if you know how to get to a particular logically defined place in the file, you will always be able to carry out copy-paste-delete to and from that place to where to cursor is.<p>One would be surprised how easy thing become once you know the basic navigation rules due to marvelous mix-n-match nature of vim operations.
As someone who works on large .NET / Java / RoR projects, would I gain anything from switching to vim from say, VS 2010, Eclipse and RubyMine? I'm quite used to relying on visual IDEs, but if vim is supposed to make me incredibly productive then I'd certainly like to explore that option.<p>Anybody here made the switch and felt it was worth it?
<a href="http://gav.brokentrain.net/projects/vimtips/vimtips.pdf" rel="nofollow">http://gav.brokentrain.net/projects/vimtips/vimtips.pdf</a><p>This PDF file has a lot of tips/command lines about Vim<p>It is also produced really well, with landscape pages and bookmarks, so that it can be displayed on your monitor very efficiently.
I've been using Vim for about three years but I've never been very handy at it. I'm now wondering that that might be because I touch type with only four fingers and whether it's possible to relearn my typing methods.
One hint I have not seen here: while in input mode use <Cntl>n to auto-complete the word you are typing. This is very good for longer variable names and ensures your name matches what you have typed already.
For me, the ultimate first lesson of vi survival is absolutely ":q!". I'm surprised it's shown only by the end of the second lesson.<p>Other than that, I hope I'll push myself to try this tutorial.
Does anyone know why the decision was made to make hjkl the vi navigation buttons? I've always felt like jkl; would be faster since your fingers are already there