Blogging Ottinger (tim)

Some people have described Vim (the editor) as a prehistoric editing environment. I don’t think it’s correct. It’s not entirely unfair especially compared with eclipse. Programming in C++ in Vim does seem rather 90s.

Vim doesn’t have to be a terribly retro experience. It doesn’t have to be awful unless you really feel like you’re cheating on emacs (a wonderful tool, also, and a good IDE if you like chording). I’m not claiming VIM is perfect or a complete replacement for a nice refactoring editor, but it is very capable and there has been a lot of work to keep it relevant over the years. I actually like using it because I have reached a point where vim is very fluid for me. I don’t pretend it’s intuitive, but it’s good.

While I’m not feeling up to anything really comprehensive, here are a few tips to making your life in VIM much more pleasant:

• GVIM — graphical vim. You’ll be glad. Learn how to use horizontal and vertical window splitting (^W commands). And tabs. It’s all there.
• Forget tabs. Set expandtabs, and use shiftwidth. In insert mode, indent with ^T and dedent with ^D. It will make you happier, especially if you dabble in python (in which case Eric3 is nice, too).
• Use the directory editor. Fire up vim using “gvim .” and you can navigate the directory as though it were a text file, including searching forward and backward. Learn to use “o” to “open” a file so that you maintain your context in the directory window.
• Use quickfix mode. Basically you type “:make” to run your makefile, and the quickfix mode will take you to each of your compile errors in order (use :cn, :cc, :cp — “:man help” will explain it.
• Use the “Man” feature. Try “:help man” for details. I ALWAYS use it, and it makes it much easier to access documentation in the editor.
• Use a unit test tool (cppunit, unit++, etc) and have your makefile run all the unit tests. Quickfix navigates unit test results as well as compile errors. It makes a lot of sense.
• Use ctags. Have your makefile update ctags when it builds. Then ^] will send you to the definition of the symbol (function name, class name, etc) under the cursor. Navigation stops being tough.
• wildmenu
• Use the ^N, luke. And the ^P. Code completion can work for you.
• Get used to the ! command. Every command-line tool you know becomes part of the editing environment. For example, highlight several lines and type !sort. Yeah, it sorted them all alphabetically, didn’t it? Use this leverage to create some of your own. YMMV if you’re in Windows (poor you). Consider using ‘astyle’ in this fashion.
• You have a lot of named buffers. Use them. Try yanking to multiple buffers when you are going to copy multiple things.
• Don’t overlook the power of the “read” command (:r) to suck in template code from text files. I never can remember how to set up a unit test class from scratch, but I know I can do “:r testclass.txt” — and the wildmenu means I don’t have to type that much of it.
• Unfortunately, vim doesn’t run a command-line window. Run your own command line window.
• Learn to use macros. If you are going to record and playback macros, you might also want to know how to insert named buffers while in insert mode. It’s handy when you want to rearrange a line. “@@” is handy.
• Look at vim.org for plugins/scripts. Maybe write one or two.

I’m enjoying the combination of gvim with ctags/fastdeps/bzr/etc. It is a very fast editing environment, even though it doesn’t color in the unit test results.