Did you ever wonder how to use Vim as an IDE? When I’m doing web development, or C/C++ on a ‘nix system, Vim (+ the OS) is my IDE.

David Rayner’s Best of VIM tips, a large collection of useful VIM tidbits.

Here’s a plugin to automatically close XML/HTML tags in Vim, and some general Vim HTML/XML tools and mappings.

If you’re a Vim user, then you’ll want to check out version 7. This latest release includes built-in spell checking, extended auto-completion, undo branches, buffer tabs (and more), replacing most of the plugins used by long-time VIers.

A few tips …

Want to load a set of files into tabs?

$ gvim -p *php *txt &

Want to revert the current file to an earlier or later version?

:earlier 25m
:later 20m

Want to see the list of undo points?

:undolist

Want to turn on omni-completion (and all file type detection)? Omni completion defaults to ctrl-X, ctrl-O to list completion possibilities (tip to make it behave more like Visual Studio).

:filetype plugin on

Other handy, new features:

:sort
:vimgrep (instead of using your shell's grep)

Never heard of Vim? Try reading Vim, explained in 6k. Also check out The best-of Vim tips for many handy bits of Vim learning.

And why do I still use Vim? I can use it anywhere, with or without a UI. I use other editors, of course, but VI is my default.

Efficient Editing With vim.

A Graphical vi/vim Cheat Sheet and Tutorial

Here’s a vim tabbar script that lists your buffers in a list of tabs along the top.

Efficient Editing with vim.  A reasonable HOWTO.

Well, it’s finally happened. I’ve been assimilated by one of the two diametric camps of editor opposition. I’ve known a bit of both editors for some time — enough that remote admin and borked X-configs aren’t a problem. But neither editor tweaked my right cortex. Until recently, that is.

I think I know what finally pushed me over the edge too. We recently re-factored our build system at work to use the Gnu autoconf system and related tools. The cool part of the whole move was the fact that we now seamlessly support building between Win32 (via cygwin), Tru64, and Gnu/Linux. I use this new system on Win32 most of the time, mostly because the components I maintain aren’t actually portable yet (but the rest of our suite is). So, when editing source, I’m torn between the Win32 way (MSVC and Textpad), and the Unix way (Vi).

I also switched from Microsoft to Redhat Gnu/Linux at home more than a year ago, and have been looking for the perfect editor — a replacement for my previous tool, Textpad. I settled on Anjuta for a while, which is a very respectable editor (and IDE). But I knew it wasn’t home. The reason: it feels clunky, as it lacks efficiency.

In pursuit of the dubious goal of producing idiot-proof, zero-learning-curve programs, even programs intended for heavy-duty use such as editors — arguably the most important piece of software you’ll use — have been turned into children’s toys, effectively expert-proofed. — Tom Christiansen

Like its Win32 counterparts, Anjuta centers around simplifying the user’s initial experience. A short path to initial discovery. The problem with this, of course, is that once you’ve discovered it, there isn’t much else you can do with it. It’s not like learning how to cut and paste offers further discoveries, like cut-5-words and paste-on-line-200 (5 keystrokes in Vi). Learning GUI interface commands also doesn’t carry over into scripting the editor, it just accomplishes the task with a minimal amount of learning. Both Vi and Emacs, on the other hand, support extensive configuration and scripted customization, based on the commands available in the editor. The GUI-centric approach is just shallow in comparison.

And, it isn’t just the shallowness or GUIness of the interfaces that is inefficient. It is also the lack of intelligent modes and copious commands. Both Vim and Emacs center around pure editing proficiency. They don’t bow to the god of idiocy, where the lowest common denominator user is hand-held through each operation. Vi and Emacs are for programmers who want blinding productivity. It’s not an attitude thing. It’s not an elitist thing. These tools are designed so people can write more code, more effectively, more efficiently. It’s a geek thing; a man-machine symbiosis thing. They are advanced tools, for people interested in advanced uses.

A good example of an efficient command is the :make command. The command builds your sources and captures the results. It then magically positions the cursor on the first error (if any) and provides a key combination to scroll through the rest of the errors. Contrast this to any GUI IDE, where the output of the build is captured in a nice window, allowing the user to point and click on each error to jump to the code. The same thing you say? Not a chance. A developer’s inner-loop is the code-compile-test cycle. Sorting through build errors with hand-mouse navigation and human-based text parsing requires universes of effort, when multiplied by hundreds of human powered code-compile-test cycles a day. Vi has it right: optimise for developer efficiency.

The greatest complaint about editors like Vi, is that the text-based key-commands aren’t intuitive. The supposition that every interface needs to be self-documenting, or plainly-obvious, is just plain bent. RTFM. Real tools require real documentation, not pictures placed on a pretty graphical facade. Real tools have depth.

The plain fact is that some tools are used for complex problems. Placing an overly-simplified interface on complexity just obscures interaction with it. When you mess with a user’s ability to interact effectively with their data, you mess with their productivity — and their ability to think about their data. In this case, the user is a developer — not someone who requires a stupefied interface. And, developers require solid, portable, accessible, efficient, open text editing tools.