Mad Computer Scientist

Now that I have written about configuring Vim to make it interact better with Visual Studio, I want to take a moment and look at some extensions that seek to put Vim in Visual Studio.

The first, probably the oldest, is ViEmu. It was the first thing I came across in my quest to use Vim’s fluid editing for .NET development. At $99, it isn’t exactly dirt cheap, but I would happily have bought a license to have Vim in Visual Studio. As an added bonus, the $99 version also integrates into SQL Server Management Studio. So, I downloaded the trial beta for VS 2010 and installed it. The addition made Visual Studio so unstable, the results were astounding. Multiple crashes, out of the blue, with no rhyme or reason–except that when I removed ViEmu, it all stopped. Apparently, I’m not the only one.

If this were an open source project, I would have been sorely tempted to dig in and see what the problem was, but it isn’t. I simply won’t buy software that makes my development life miserable.

Later, I stumbled across VsVim, an open source project with very similar aims to ViEmu. So far, this has proven to be very, very nice. It detects conflicts between its keybindings and Visual Studio. The biggest signs of its overall youth (VS 2010 is the only version it supports, or ever has), is that there are many motions that are not fully implemented. For example, if you move the cursor over to an opening parentheses or brace in command mode, and type ‘d%’ without the quotes, you get an invalid motion error. In Vim proper, it deletes the parentheses and everything between them.

Looking at the project activity on GitHub, it looks like there is a good deal of activity, which is always a plus on these kinds of projects. The only real oddity is that the author cannot accept source contributions. I guess if anyone wants to make significant changes, they will have to fork it.

Overall, I am very happy with VsVim and am using it day to day. I still use gvim alongside it for those cases that I want to get full vim happiness (and, especially, when I am in familiar enough territory that I don’t need or want IntelliSense.

My new job is writing in C#/.NET. Overall, I like this quite a bit. C# has some nice features over Java (I went to a Java school, so I do speak from experience) and the .NET framework is quite nice. I have, though, been having to optimize Vim for .NET development and wanted to share some handy links.

1. http://kevin-berridge.blogspot.com/2008/09/visual-studio-development.html — a very nice series on setting up Vim with C#.
2. http://arun.wordpress.com/2009/04/10/c-and-vim/ — Some excellent suggestions here, particularly in making ctags a little more automatic.
3. http://stackoverflow.com/questions/1747091/how-do-you-use-vims-quickfix-feature — some questions about vim’s quickfix feature.
4. http://vimdoc.sourceforge.net/htmldoc/quickfix.html#quickfix-window — documentation on using vim’s quickfix feature.
5. http://www.vim.org/scripts/script.php?script_id=356 — dbext makes life so much easier.

At least the first link there suggests the use of NERDTree. While I have used NERDTree in the past, it was definitely more useful with Visual Studio, because the hierarchies ran deeper than is, I think, typical in other projects without it.

ctags is wonderful for cross-referencing code within the project itself. The suggestions at link #2 were particularly helpful in getting things set up so that updates to the tags file would happen automatically in a timely manner.

Some of you may ask, why not use ViEmu? The answer is: I tried. I tried hard and I wanted to like it. It is less set up time and less hassle to have Vim in Visual Studio than it is to build just the right amount of bridging between Vim and Visual Studio. The problem I hit was that ViEmu crashed Visual Studio 2010. Often. Badly. Irritatingly. The stability hit was just too much.

Team Foundation Server is another big one. I had to tinker with it a little bit, but link #1 provides some good pointers on getting this set up.

Finally, here are three files:

• dotnetvimrc.nw
• _vimrc
• _gvimrc

The first file is a literate explanation of the configuration files. The second two are the tangled output. If you want a more thorough explanation of what is going on, consult the first file before moving on. Anyone with comments or questions, feel free to post them here. Some things I am still looking for in my .NET vim config:

• Better designer integration support. Visual Studio’s ASPX designer generates code (the *.designer.cs files) based on events that happen in the IDE–not as part of the build process. This means that making wide ranging changes outside the IDE causes compilation errors that can only be fixed by opening the .aspx file and making a change or two (I tend to cut the whole file and paste it back into itself), then rebuilding.
• A communication bridge between Vim and the debugger would be nice.
• Similarly, it would be nice to launch the embedded IIS server from within Vim.