The single most important concept to remember about Vim, IMHO, is that Vim commands are sentences. The structure is action, number, movement. (Or number, action, movement if you prefer). E.g., "d3w" deletes from the cursor to the start of the 3rd word after the cursor -- because that's where the movement command "w", repeated three times, will end up.

Once you understand the sentence structure of Vim commands, it becomes a lot easier to figure out the right command for whatever text modifications you're trying to do.

I first started using vim for quick edits on remote unix servers, but it quickly grew to be my editor of choice for general programming - I even install it on my Windows systems. With the right plugins from vim.org it can do many of the things you would normally use an IDE for.

My hot tip is to get familiar with the :ex commands. My favorite is the :global command (abbeviated to :g) which executes another command on every line that matches a regular expression. The command to execute defaults to 'print', so for example
:g/^ *def/
will print every function definition in a python file.

The command that global runs can also have a range modifier, so for example:
:g/^ *def/ -3,+3p
will print every function definition and the three lines before and after, while
:g/^# *TODO/ ?^class? p
will find every line with a TODO comment, then search backwards for the class definition and print that.

I also recommend upgrading to Vim 7 wherever possible, since it adds many useful new features.

I also recommend this PDF cheatsheet - it is pretty comprehensive:
http://tnerual.eriogerg.free.fr/vimqrc.pdf

I've been using vim for about half a decade now, but every time I go back and read http://www.rayninfo.co.uk/vimtips.html I either learn something new, or am reminded of something cool I once knew. It's not the sort of thing you read casually and ponder it, it's just a whole bunch of keystroke recipes, but it quickly explores a wealth of features in the editor.

Oh, and welcome to the dark side. :)

Funny, whenever I need to do something quick and simple on Linux, I just load up the quick and simple Pico or Nano (http://www.nano-editor.org/). I guess its that "avoid a chainsaw to cut a piece of tissue paper" approach.

My calculation is somewhat simple: If it requires more keystrokes to control the editor than it takes to actually change the content, I'm probably using the wrong tool. The corollary: If using the tool require using more than one modifier key in a row (ctrl, alt) or backslashes, its probably the wrong tool for quick edits.

Yes, those who live-and-love E(macs) or V(i/im) are welcome to them, of course; I know they can edit circles around me. I just don't have the patience to memorize the "sentences" or idioms for E or V. Every year, I try, and every year, I laze on back to nano. One day, someone will discover that the presence of nano or pico is what's been holding back the conquering of Linux over Windows, it'll be dropped from distros, and I'll be in trouble...

I recently blogged about using Vim 7.0's built-in autocompletion feature, I use it with Python and it's great.

http://here.the.ycros.be/article/the-omnipotent-vim

I keep being forced to use tools like eclipse, which just seem to slow me down. And then I find myself typing vim commands into them and spending a second being all confused as to why i suddenly have a dd in my text and the line hasn't gone away, or more frequently, why a :w suddenly appeared.

Auto-completion is something that I miss in vim but it doesn't exist for ruby (AFAIK) and using it in eclipse tends to slow me down or cause typos because the computer is slower than my typing or thinks I want something I don't, unless of course I'm working in an unfamiliar code-base, in which case it's pretty useful. There's a vi plugin for eclipse but last time I checked it wasn't free.

Autocompletion _does_ exist for Ruby. It's included in Vim 7.0, if you have it compiled with Ruby support. There are some updated scripts and configuration files in one convenient download at http://vim-ruby.rubyforge.org/

If it's a quick edit, I think I subconsciously choose vi over emacs simply to save 500ms of startup time.

>If it requires more keystrokes to control the editor than it takes to actually change the content, I'm probably using the wrong tool.

Couldn't agree more.

:q!