A few months back I commented that I had gone back to using Vim as my text editor when not using Visual Studio, and to be honest, I haven't regretted that at all.

I'm not a Vim power user by any measure, but I do get around and I'm constantly learning and looking for new bits and trying to get them into my muscle memory. It's a bit hard, but it's already been very productive and I'm slowly getting the hang of it.

Now, I had used Vim before this many years ago, but I now realize that I didn't really "get" Vim at that time. Sure, I could open, edit and save files, but I wasn't really tapping into the features that make Vim so powerful as an editor.

I also realized that one of the things that was seriously keeping me form becoming a better vimmer was that having to push two completely different kinds of text editing metaphors into my finger's muscle memory (and my own memory, for that matter) was simply too hard. While I tried to learn a few Vim tricks here and there, I would always fall back to the old classic text editing used throughout windows (and, most importantly, in my primary editor: VS).

I also realized that I really didn't get the power of Vim's three modes (normal/insert/visual). In particular, I never really learned how to use Visual mode effectively.

This time, however, I set out to remedy that. After learning a bit more about Vim and getting the hang of a few things, I finally caved in and got a copy of ViEmu, after having it recommended to me by both Aaron Jensen and John Lam.

This is a fantastic tool and has made, for me, all the difference in the world. ViEmu pretty much puts a substantial piece of Vim's power as a text editor right inside Visual Studio (and it works great with VS2008, by the way). This meant that I could now seriously learn more Vim tricks and be able to take advantage of them in both my main text editors.

Having that capability makes it a lot more worthwhile and encouraging to actually spend time improving my Vim skills. I'm still not even a mediocre vimmer, but I'm now using it much more effectively. Seriously, if you want to learn Vim, and are a .NET or Visual Studio developer, you ought to take a good look at ViEmu; I can't recommend it enough.

By the way, ViEmu got a slight price increase, but even at the new price it is well worth it and more than pays for itself. The licensing model works great as well: It is licensed per-user, which means I can install my copy, for example, in my three development virtual machines.

If I spent enough time inside MS Word, I'd buy the Word version as well (fortunately, I don't!). I'm sure I've left a few ":w" inside a document or two .

Vim, ViEmu, Text Editors

Aaron Jensen has put up a short screencast on using Vim, showing some of the tricks you can use when editing text with it; very cool stuff.

Some other Vim resources that might be interesting:

• Daniel Webb has a few short videos on Vim.
• Vim: 7 Habits for Effective Text Editing. A lecture by Vim creator Bram Moolenar. A little on the long side, but some useful things here and there.
• MacVim: I don't use a Mac, but this looks way cool (I love Vim, but it is ugly ).
• A couple of good Vim tutorials.

Vim

Quick question: How many of you use the 'View White Space' feature in Visual Studio?

In case you're not familiar with it, this feature makes the VS code/text editor display a small dot everywhere there's a space and a small square at the end of the file, thus making it easier to visualize white space. Here's how it usually looks:

The 'View White Space' feature can be activated through the Edit -> Advanced -> View White Space menu option, or using the Ctrl+R, Ctrl+W key combination (at least on my keyboard layout).

Personally, I only use this very rarely, though I admit it is occasionally useful, for example when working with positional flat files. I do wonder, is there any of you that uses it full time while coding?

Visual Studio

As everyone and their mothers already know, Google recently started activating IMAP support on Gmail, and it looks like most people seem pretty excited about the announcement.

Now, personally, I seem to get by fairly well just using good old POP3 access, and a few filters on the server and my own custom list of folders on my Outlook PST files where I organize mail I want to keep. It's not exactly elegant, but it's what I'm used to and sort of works, though I'll be the first to admit it is kind of awkward to have some email here and some email there and in different locations.

I've never really used IMAP, but I'm willing to give it a try, who knows, maybe I've been missing out on all the fun! So what do I do? I go into outlook, delete my old Gmail account, and create a new one set up with IMAP.

What is the next thing I notice? For some reason, Outlook 2007 seems to believe that if you choose to use IMAP, you're not worthy of choosing the location of your PST file on disk: the file must be on your Windows profile directory in one of those useless, awfully hidden, un-backupable directories (i.e. C:\Users\<user>\AppData\Local\Microsoft\Outlook\...). Isn't this an extremely silly restriction to have on a mature, v12 product?

Outlook

Jeremy Miller asked about switching from NAnt to MSBuild and if it would be worth it. I've thought about this in the past, and here's what it always comes out for me:

• In raw power and flexibility, I don't think there's a clear winner.
• MSBuild has the advantage of being "built-in" and that as Microsoft itself extends the compilation process (or brings more things into it, as is the case with, say the Workflow Foundation validation targets), it will have some stuff earlier than NAnt.
• NAnt, however, has a fairly extensive (more extensive, I'd say) set of tasks, if only because it has been around earlier and has a good community around it.
• Personally, I prefer NAnt's structure; I find it easier to read and maintain than MSBuild's one. This is pretty significant to me because build scripts can easily get fairly complex. Syntax itself is irrelevant here because both are XML dialects.
• Documentation for NAnt is, I'd say, far better than for MSBuild. In particular, I found MSBuild documentation to be pretty useless in general because what you will usually find documented is the API (raw methods and properties) of the MSBuild task classes, instead of documenting them in a way that more obviously maps to how you would actually use them in a build script.
• It might be wise sometimes not to choose one over the other, but instead have them collaborate.
• If you need multi-targeting support (that is, compiling a single code base against multiple framework targets), then NAnt is the clear winner here. NAnt's framework support is pretty good and it's very easy to create a build-script that can compile a single code based against .NET 1.1, 2.0 and Mono. MSBuild is rather lacking in this area (MSBee can help with .NET 1.1, but it really is a hack and a pain in the neck to use).

In general, I would say that if you're already familiar with NAnt, and can use it effectively and efficiently, there is little compelling reason at this time to switch. But if you're not familiar, then at least trying to get acquainted with MSBuild should be worth it.

NAnt, MSBuild