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.

Writeboard is yet another nifty 37 Signals web tool. It’s a web-page/whiteboard app that lets any number of people edit a page at the same time, or in other words: a wiki without the suck.

It seems that the killer traits of good web applications are:

• Simple as pie
• Do one thing well
• Smaller is better
• Connect to other things easily
• Bring people (or ideas) together
• Free or free, either will work

I upgraded to a Pro flickr account on the weekend, and am testing its blog-a-shot feature. If you’re reading this, then it’s working.

The feature is a cool concept too: you upload pictures (or email them), annotate them, and show them off to your friends. To make a blog post, you click on the blog-this button on any picture page, and pick the weblog to post to (and it does the rest). You can select a template for the post too, which is cool in itself.

The reason I decided to upgrade was to up my bandwidth for this month, as I decided to make a book of photos for a gift later this year. There’s a funky service that will print a full-colour, bound book for a reasonable price — all from a flickr account.

For my first book, I picked 80 photos and turned them into contrasty black and white shots, leaving a few (carefully selected) spots of colour. I’m curious to see how it turns out, as a few of the shots were less than 300 DPI.

I’ve been playing with WordPress 1.5 and the Markdown plugin that ships with it, and I’m impressed. The new version of WordPress adds several key features, including custom pages, improved comment-spam tools, theme support, and a really slick default theme. And while I’ve seen Markdown before (it shipped with WordPress 1.2.2, and was available for MoveableType) this is the first time that I’ve taken the time to really learn it. Both Markdown and Wordpress 1.5 are solid tools.

Markdown is good enough that I’m going to use it in place of my MagicMarkup tool. It’s similar to Textism and ReStructuredText, providing a natural markup syntax for writing weblog articles. So instead of maintaining my MagicMarkup tool, I’ll continue to write extension plugins for WordPress and other great tools, for functionality that doesn’t exist yet. It seems futile to pollute a solution space that’s arlready populated with many intelligent products.

The ‘pages’ feature in WordPress brings it closer to a Wiki, allowing you to add arbitrary pages to a website. They solve problems like project pages, archives, and other non-article content. I can see using this feature for extending my site to include other web tools, without having to hack pages in by hand, though I’ll still have to write a plugin or two.

As WordPress and Markdown are good enough for my purposes, I can cut out two of my larger personal projects (BenderBlog and MagicMarkup). In their place, I’m working on a few plugins:

I purchased and installed Codeweaver’s CrossOver Office today, a professional repackaging of Wine is not an emulator. I’m finding that none of the Gnu/Linux-native office tools are quite robust enough for import/export of Office documents (though they are getting close), and the vanilla Wine RPMs are not that stable. I do like using Open Office and Gnumeric for creating new documents, but I’m having trouble with a few important client-related documents (and I’m not a purist).

So I decided to try CrossOver. The really cool thing is that it just works, and it’s fast (faster than native it seems). It is a bit weird, though, to see the Word and Excel icons on my Gnome toolbars.

I’ve been quietly changing my web-browsing habits over the last few months. I now use Bloglines, a free (as in beer) web-based RSS aggregator for browsing news, weblogs, link logs, and finding random intelligence. So far I’ve avoided reading stuff via RSS, mostly because I find that aggregators provide a monochromatic view of the web.

Combined with the incredible random-access link services provided by Google, I now view the web almost exclusively in aggregate form. Where I used to visit dozens of sites daily for news and tech bits, I visit two. It’s simpler, more efficient, and it lets me spend less time reading (yet read more of what I want to).

Slashdot style news, comment, and link aggregators are now old-school, as better information is available directly from the source. Insider news, commentary, and meta-commentary is now readily accessible right from the people who are part of the actual events, instead of through the indirection and filtering of news editors.

We are now our own news editors, writers, and publishers. Not only are the levels of indirection reduced, a few layers of prejudice are removed. It’s a set of Freedoms that I didn’t really see coming out of the net, and I’m not sure how it will play out. But the result is incredible, and I like it.

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.