Fifteen months after the release of Vim 7.1, Bram announced the release of Vim 7.2 last weekend. No major new features, just the consolidation of more than 300 patches. He also included a mention of the new distribution point for Win64 binaries, the vim-win3264 project that I set up at Google Code.

Bram has no way of testing the Win64 version, so I'm providing the official build at vim-win3264. I will no longer provide Win64 binaries for Vim from my own site. The Vim 7.2 sources compile the Win64 binaries cleanly (unlike the 7.1 release). I'll provide occasional intermediate releases up there too, for both Win32 and Win64.

I'm rather surprised to see that the Win64 binary has already been downloaded 248 times in the last week. It's such a pain to look at the logs on my server that I have no idea how many times earlier binaries were downloaded.

Tomas Restrepo wrote a post about sharing dotfiles between Windows and Ubuntu, specifically about sharing .vimrc (Linux) and _vimrc (Windows) and the .vim (Linux) and vimfiles (Windows) directories.

I have a different solution. On Windows, my C:\AutoExec.bat includes:

set HOME=C:\gvr
set VIM=C:\Vim
set VIMDIR=%VIM%\vim71
set EDITOR=%VIMDIR%\gvim.exe
set PATH=%PATH%;C:\Win32app;C:\GnuWin32\bin;C:\UnxUtils;C:\SysInternals;C:\Python25\Scripts

%HOME% (C:\gvr) contains _vimrc, vimfiles, and other stuff accumulated over many years. This directory is stored in a personal Subversion repository at DevjaVu. All my Vim files are stored with Unix LF endings, not Windows CR-LFs, so that they'll work on my Mac OS X and Linux boxen. I play some games with if has("win32") and if has('gui_macvim') to ensure that my _vimrc works cross-platform.

On my *nix boxes, the gvr folder lives under my home directory at ~/gvr, and ~/.vimrc and ~/.vim are symlinks:

$ ln -s ~/gvr/_vimrc ~/.vimrc
$ ln -s ~/gvr/vimfiles/ ~/.vim

In addition, the dotfiles that I keep in SVN are stored locally in ~/gvr/dotfiles without a leading period in their names, which makes them easy to see:

$ ln -s ~/gvr/dotfiles/bashrc ~/.bashrc

This arrangement works well for me.

Use O'Reilly Maker to generate book covers. I've always wanted to write a book for cousin Tim, and now I have!

Via Pavel: Adolf Hitler - Vista Problems (YouTube).

The Photographer's Right: a handy one-page guide.

The general rule in the United States is that anyone may take photographs of whatever they want when they are in a public place or places where they have permission to take photographs. Absent a specific legal prohibition such as a statute or ordinance, you are legally entitled to take photographs. Examples of places that are traditionally considered public are streets, sidewalks, and public parks.

The tiny <code> font in Firefox has been bugging me for a long time. I finally figured out the obvious: Override the Monospace setting. Tools > Options > Content > Fonts & Colors > Advanced > Monospace: change Courier New at size 13 to 16. While you're at it, change the font to Consolas or Lucida Console or Monaco. Courier New is ugly.

My man, John Edwards, is out of the presidential race. Some analysis from Corrente and Meteor Blades of Edwards' candidacy.

I have never been enthusiastic about Hillary Rodham Clinton as a presidential candidate. She's accumulated 16 years of negatives from being relentlessly demonized by Limbaugh and his ilk; she's too damn centrist and corporate for my liking; and I remain troubled about her vote for the Iraq War and her refusal to apologize for it.

I am now an Obama voter. I have expressed some doubts in the past about his efficacy, but there's no doubt that his messages of transformation and inspiration are striking a chord with primary voters.

The Washington state primary on February 19th is a complete farce, at least if you're a Democrat. The Democratic presidential candidates are entirely chosen by the Washington state caucuses on Saturday, February 9th. Washington state law requires that a presidential primary be held, but the parties are not actually obliged to select any delegates as a result of the vote. The Republicans delegates will be allocated 49% from the caucus results, and 51% from the primary results.

I'm the Democratic Precinct Committee Officer for SEA-1945, and I'll be participating in our neighborhood caucus at Asa Mercer School. I need to phone participants of the previous caucus today, both in my own precinct and some adjoining, PCO-less precincts, to remind them of the caucus.

I've uploaded Vim syntax highlighting for PBwiki, a free, hosted wiki that I've used for a few different projects.

Miscellaneous links.

• I've uploaded Vim syntax highlighting for Socialtext, the wiki we use at Cozi. Amusingly, it's derived from code that I found on the Socialtext website, which in turn is derived from my syntax highlighting for Flexwiki.

• Ignite Seattle is back on 2/19. There were lots of interesting, geeky talks the last time I went.

• Via Slashdot, Walter Kirn on the failure of multitasking

  Through a variety of experiments, many using functional magnetic resonance imaging to measure brain activity, [scientists have] torn the mask off multitasking and revealed its true face, which is blank and pale and drawn.

  I have a moderately bad case of multitasking myself.

Picture this.

An external USB hard drive plugged in to a machine running Win64. The OS has virtualized the underlying transport so that it's essentially indistinguishable from an internal IDE, SCSi, or SATA drive. Call the machine, Boss, and the USB drive, L:.

Boss is running Virtual PC, which is hosting a 32-bit virtual machine on top of Boss's 64-bit OS. Let's call the 32-bit VM, Sidekick.

Sidekick is not only a VM, but a virtual network host. Boss is bridging connections to Sidekick, and Sidekick and Boss both appear on the LAN as separate network hosts.

The USB drive has several ISO images, which Sidekick wants to use. Sidekick connects to \\Master\L$ over the virtual network, and uses a tool like VcdTool to mount the remote ISO on a virtual CD drive.

Amazingly enough, it all just worked for me last night.

I'm trying to set up an environment where I can build Vim with various 32-bit and 64-bit Microsoft compilers and, more importantly, run the Win64 binary. I have a set of VM images with distinct flavors of MSVC, which was necessary to update INSTALLpc.txt and to keep Make_mvc.mak building.

In previous iterations, I got Remote Desktop access to a colleague's Win64 machine, but that was at Atlas, so it's no longer an option. I bought a new AMD64 desktop system a few months ago and over the weekend set it up to dual boot.

I have updated the Win64 port of Vim. It now includes a working installer, a working "Edit with Vim" shell extension, and the first 195 patches for Vim 7.0. Get it while it's hot!

As I mentioned last month, I participated in this year's AIDS Walk on Saturday.

I raised over $1300 online, handily exceeding my goal of $1,000. I also raised another $300 in cash and checks at the fundraising barbecue that we threw on September 1st.

I've lost count, but I believe that in the last 15 years, I've raised about $10,000 for charity. Most of it has been for the Northwest AIDS Walk. The last few years that I was at Microsoft, I raised $2,000-$3,000 each year, thanks to the power of Microsoft matching, which doubled the amount of money that I raised. I've also raised money two years running for Ugandan orphans sponsored by Vim: Microsoft Vim Users raised $2650 for orphans in Uganda.

Go me!

More than two years in the making, Vim 7.0 is finally out!

(Vim is Vi IMproved, an enormously enhanced version of the classic Unix editor, vi.)

The main features of the 7.0 release are:

• Spell checking

• Omni-completion (Intellisense-like)

• Tabbed pages

• VimL script language now supports Lists and Dictionaries

I'm going to take credit for some minor features of Vim 7:

• Making Vim build with VC5-VC8

• The Win64 port

• Syntax highlighting for FlexWiki

WikiPedia summarizes the history of Vim. This enabled me to pinpoint when I first became a contributor to Vim, back in December 1995. I cleaned up the original, rather buggy port of Vim 3.0 to NT, and posted it to the comp.editors newsgroup. Bram invited me to merge my changes into Vim 4.0, which was then under development, and I became the owner of Win32 Vim for the next couple of years.

We use FlexWiki at work. It's an ASP.NET-based wiki, a low-overhead, organic way of sharing knowledge.

The only built-in means of editing a page in FlexWiki is to type into an HTML textbox, which is a horrendous user experience. There's no WYSIWYG feedback showing you whether you've got the wiki markup right.

Back in December, Emma and I went to the Oregon coast for a week. We had no Internet access and long dark evenings, so I spent quite a bit of time on my laptop, working on a couple of projects. One was a new theme (skin) for DasBlog, which I didn't finish to my satisfaction. I really ought to get back to that.

The other was Vim syntax highlighting for FlexWiki, partially because it's useful in its own right, partially because I wanted an excuse to learn the arcane syntax highlighting mechanism in Vim.

As you can see in the picture, syntax highlighting makes the wiki markup a lot clearer than it would be in black-and-white.

I got it working satisfactorily in December, but I didn't get around to releasing it on the Vim scripts repository until last week. The week before, Bram had issued a final call for submissions of scripts for Vim 7.0, which galvanized me into releasing it as the FlexWiki Plugin for Vim.

Bram has included it in the most recent beta, Vim 7.0g, after I made a few changes. Those changes have not yet been propagated into the standalone version, but I'll try to do that later this week.

Vim and DasBlog, two open source projects that I'm associated with, have both switched over to using the Subversion source code control system in the last week. In both cases, the prolonged problems with anonymous CVS access at SourceForge proved the final straw. And I provided the impetus, by bringing up the need for a change on the vim-dev and dasblogce-developers mailing lists. I take no credit for doing the work, however, as that was done by others.

(Vim's primary repository continues to be CVS, with Subversion acting as a mirror for anonymous access. Bram didn't want to change over until after Vim 7 ships.)

Earlier this year, we switched over to Subversion at work, after years of using Visual SourceSafe. It was a huge improvement. Having to use VSS was a big shock to my system, after years of using Source Depot at Microsoft. Transactional checkins are really nice and I've grown to like TortoiseSVN as a front-end to Subversion.

I've ported Vim to Win64. Native binaries for AMD64 can be found on my Vim page.

In the end, it wasn't all that hard. Last weekend, I fixed approximately 400 warnings that were thrown up by the x86_amd64 cross compiler. Most of them were due to the widening of size_t (especially the value returned from strlen()) and ptrdiff_t to 64 bits. Several years ago, I went through a similar exercise in fixing these warnings for Vim6, but I never finished the port.

This week, I scrounged access to an AMD64 box at work. Today, I turned on the /Wp64 flag, which found several new, subtler problems, where pointers where being truncated to __int32s or conversely __int32s were being widened to pointers. Judicious introduction of (the equivalent of) (INT_PTR) casts fixed most of those.

At that point, I tried running the binary. It refused to start! After a few detours, I had WinDbg installed, and ran gvim under WinDbg. That showed that the error was 14001 (ERROR_SXS_CANT_GEN_ACTCTX, "The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail.") The event log showed nothing.

After more investigation, I found a WinSxS manifest for the Windows Common Controls:

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <assemblyIdentity
     processorArchitecture="X86"
     version="6.2.0.0"
     type="win32"
     name="Vim"
   />
   <description>Vi Improved - A Text Editor</description>
   <dependency>
     <dependentAssembly>
       <assemblyIdentity
         type="win32"
         name="Microsoft.Windows.Common-Controls"
         version="6.0.0.0"
         publicKeyToken="6595b64144ccf1df"
         language="*"
         processorArchitecture="X86"
       />
     </dependentAssembly>
   </dependency>
 </assembly>

Once the two instances of processorArchitecture="X86" were set to processorArchitecture="AMD64", Vim started working without a hitch. Despite my naïve expectations, none of the other fields in the comctl32 assembly needed to be changed.

Vim vs. Visual Studio

I've been an obsessive vi user for more than 20 years. Vi keystrokes are indelibly burned into my muscle memory. When I have to use Notepad or Word or Visual Studio, I feel crippled. I have to work harder to do simple things; I have to type too many chords with Alt and Ctrl; I have to take my hands off the home keys to use the cursor keys and the mouse.

In the mid-90s, I adopted Vim (Vi IMproved) to the point where I became a significant contributor, writing a big chunk of the Win32 code.

While I was at Microsoft, I hardly ever used Visual Studio. I edited my C/C++ code with Vim, I compiled and linked it with the NT Build Environment and I debugged it with WinDbg/ntsd/kd. I was hardly alone in this. In the Windows division, your code has to build with the NT build environment, and the Windows debuggers are much better supported than the Visual Studio debugger for developing the OS.

Now that I'm programming in C#, using the Visual Studio IDE makes a lot more sense. VS's IntelliSense for C# is much richer than Vim7's Omni completion, especially when coupled with ReSharper, and VS is the debugger of choice for managed code. I've been spending a fair amount of time in the VS IDE, especially when pair programming, but I've also been switching back to Vim a lot. When I'm struggling with unfamiliar code, VS's IntelliSense is a great comfort; when I'm moving a lot of text around, Vim suits me far better.

ViEmu

Earlier this week, by way of its graphical Vim cheat sheet, I found an interesting compromise. ViEmu is a vi/Vim emulator for VS 2003 and VS 2005.

ViEmu implements most of the vi keystrokes and many of the Vim extended keystrokes, right inside the Visual Studio IDE. It uses the native VS IntelliSense in place of Vim's completion functions. ViEmu even implements some of the more common Ex command line, including most of the :%s regular expression substitutions. The author, who seems to be known only as JNG, is responsive. Within 24 hours of my reporting some missing keystrokes, he had implemented them in a new minor release.

It does not, however, support VimL, the Vim extension language, so if you have an extensive suite of Vim plugins, as I do, they're not going to work in ViEmu.

All in all, I'm favorably impressed with ViEmu. It provides much of the muscle memory experience of Vim inside of Visual Studio. Technically, it can't have been easy to impose such a radically different input model on VS or to emulate Vim and Ex fairly faithfully.

Vim has always been free (actually charityware), but JNG charges for ViEmu. Right now, I'm in the 30-day trial period, but I fully expect that I'll pay for a license before the trial is up.

VisVim

Vim comes with a Visual Studio add-in called VisVim, which is based on another add-in called VisEmacs. It allows VS5 and VS6 to use Vim as the default editor, albeit externally to the IDE: Vim continues to run in its own window.

A few weeks ago, Bram asked me if I could get VisVim to compile with VS 2003. I tried, but I was unable. Necessary headers are no longer included with VS 2003 or VS 2005. No doubt this is because the Add-In architecture changed radically with the introduction of Visual Studio .NET.

Work is underway, albeit very slowly, to create VisEmacs.NET. At some point, it may be worth creating a merger of VisVim and VisEmacs.NET.

End Notes

viWord allows you to use vi keybindings in Microsoft Word. It's not nearly as full featured as ViEmu and I found that I didn't like it enough to keep it around.

This post was, of course, composed in Vim. I wrote it in lightly marked-up plain text and converted it to HTML with VST, Vim reStructured Text. Blogging with VST will be the topic of a future post.

To fully take advantage of Vim7's Omni completion, you need a patched version of Exuberant Ctags. I've made a Win32 binary available.

I often complain about being busy, no doubt because I have a talent for complicating my life. Things were relatively quiet for a while, but that's not true anymore.

At work, we're close to releasing the first version of our product. Happily, crunch time at Atlas isn't nearly as bad as it was at Microsoft. Instead of working eight-ish hours a day, it's more like nine or maybe ten. The pressure level has risen, of course, but it's far from intolerable.

The real busyness is in my extracurricular life. I'm the president of BiNet Seattle, a bisexual community group, and have been for the last three years. I also do a hell of a lot of the work and I'm burning out. I recently gave notice that I'm stepping down. (It looks like a successor has been found.) Meanwhile, a lot of planning is going on in an effort to revitalize BiNet, as attendance has been dragging.

For the last few years, I've also been heavily involved with The Wild Geese Players of Seattle, as the webmaster and the co-dramaturge. We do readings of Irish literature, particularly that of James Joyce and W.B. Yeats. Every June 16th (Bloomsday), we do a staged reading of a chapter of Ulysses. This year, the longtime director has moved back to Northern Ireland. Currently, I am acting as the director, on top of my other roles, but I don't think I'm the right person for the job, and I'm hoping to find a replacement soon.

I'm a member of Freely Speaking Toastmasters, an LGBT speaking club. I've been working on my CTM for far too long, and I intend to knock off the final three speeches this year.

I resume my woodworking class next week, which is going to tie up ten Tuesday evenings. I haven't decided yet what I'm going to work on this time. In previous years, I built a very nice set of nesting tables and an unsatisfactory pair of bar stools.

In my Copious Spare Time, I'm also making occasional contributions to two open source projects, DasBlog and Vim. I made Vim compile with VC5-VC8, and I promised Bram that I would provide some documentation on debugging Vim with WinDbg and dealing with minidumps. I'd also like to produce a native Win64 version. With DasBlog, I've provided some feedback on the usability of the installation instructions, as well as a fix for dodgy permalinks. I'd also like to make use of my former expertise on IIS performance (see 25+ Tips, 10 Commandments, IIS 5 Tuning, and Professional ASP 3.0) to do some performance tuning of DasBlog.

I'd also like to fit in some time for photography; for reading my way through our enormous backlog of books and magazines; writing the occasional blog post; cooking; bicycle riding; traveling; working out; hanging out with my wife; socializing with my friends; movies; and more. Not to mention all the very dull projects around the house and garden that I've neglected.

I've been trying to make Vim 7 compile with the Microsoft Visual C++ 2003 Toolkit, as a favor to Bram Moolenaar, the primary author of Vim. He wants to be able to use the free compiler as the primary build tool for the Win32 version of Vim.

Oh. My. God.

The VC2003 toolkit may include a full optimizing compiler, but it's certainly far from a complete system for building Windows binaries.

First, I discovered that it came only with the C library headers, but not the Windows headers. That was easily rectified. Download the Platform SDK. Just the Windows Core SDK subset. This also got me nmake.

At this point, I was able to compile Vim, but not to link it. The linker required cvtres.exe, to link some resources. Some googling showed me that this is included in the .NET Runtime.

The main Vim executable now linked, but the shell extension DLL didn't. I didn't have msvcrt.lib! It took me more detective work to learn that I'd have to install the .NET Framework SDK to get msvcrt.lib. There are several clever hacks out there that generate msvcrt.lib from msvcrt.dll, with the help of link -dump -exports and a sed script, but these do not include the all-important _DllMainCRTStartup@12, the real entrypoint for DLLs linked with msvcrt.

All the necessary steps for getting the downloads are summarized on the Code::Blocks wiki. Code::Blocks is an open-source IDE that can host the VC2003 toolkit, GCC, and a number of other compilers.

So why bother with the VC2003 toolkit, since Visual C++ 2005 Express Edition is freely downloadable?

The main reason is that it's free only for the first year, and Bram wants something that will still be available after November 2006, so that anyone can compile it.

I have also ported Vim 7 to compile with VC2005 Express. It was fairly straightforward, after I had added the following

 #if _MSC_VER >= 1400
 # define _CRT_SECURE_NO_DEPRECATE
 # define _CRT_NONSTDC_NO_DEPRECATE
 #endif

to shut up the warnings about deprecated CRT functions. I also had to make it link with libcmt.lib (multithreaded) instead of libc.lib, as the single-threaded static library is gone.

I still need to make sure that everything continues to work with the retail compilers, VC6, VC7.1, and VC8, before passing my changes back to Bram. Sigh.

Update #1: I almost forgot. VC2005 Express also requires the Platform SDK to build Vim.

I'll send the diffs to Bram in about a week. I'm too busy to clean everything up this week.

Update #2 (2006/03/12): I sent updates to Bram a week ago and he's checked them into the Vim7 source tree. Be sure to read src/INSTALLpc.txt, section 1, for details on compiling Vim with VC5-VC8.

Update #3 (2006/04/22): VC2005 Express is now free forever. Vim7 is in beta and will be released soon, and Bram doesn't want to switch compilers at this point.

vi. Vee-eye. My text editor of choice for 20 years. Half my life.

Why? Because I imprinted on vi, like a duckling on its mother. Vi's keystrokes are bound into my muscle memory. My fingers reflexively use vi keystrokes to move around, to delete text, to move blocks, to find patterns. I don't have to think about using dw to delete a word, or n to find the next match of a pattern, or yG to yank the rest of a file, or j to move down a line, or . to repeat the last modification. My subconcious does it for me.

I don't even have to think much about more complex commands, like ct) to replace a parameter list, or simpler regexp replacements. I've internalized so many vi idioms in the last two decades.

For nearly all editing tasks, I'm far more productive when I use vi. Like Tom Christiansen, I can become at one with the machine.

People who've used vi fall into a bimodal distribution. They love it or they hate it. Usually, it's because of vi's modal nature. I love the orthogonality of the UI.

20 years

In the autumn of 1985, I entered my third year of Computer Science at Trinity. We were promoted from three hours a day on the 1200-baud terminals in the basement to all-day usage of the 9600-baud terminals in the main terminal room. We also graduated from the wretched SOS line editor to vi running on Eunice (a Unix emulator for VAX/VMS). I don't think I took to it instantly; it took a little while for it to grow on me. Soon enough, though, I was hooked on regexps.

Hitting ESC quickly became a habit: one that causes me occasional grief, when I reflexively hit ESC after entering text in an edit field in some app or other, and destroy what I've just written.

Two years later, I got my first fulltime job, writing a full-screen text editor for a small Irish typesetting company, ICPC. It was a replacement for the in-house line-based editor used by the data entry keyboaders, which I wrote in Vax Pascal. A friend made me aware of VITPU, a Vi emulator written in VMS's TPU, which I gladly latched onto.

Two years after that, I entered the Master's program at Brown, where I first got to use Unix and X Windows. Naturally, I used vi, but it was a lot less powerful than GNU Emacs, which was very popular. In time, I learned of VIP, a vi emulator for Emacs. I began using VIP and quickly forsook standard vi. I liked having the power and customizability of Emacs, though I never learned to like the Emacs keybindings. (François Pinard, a longtime Emacs user, writes eloquently of why he moved to Vim.)

I stayed with VIP for years, as it evolved into Viper. I show up in the Viper credits for occasional contributions.

In 1992, I moved to Seattle and worked for Microsoft for the first time. I kept my Emacs+Viper habit.

By 1995, I was working for MicroCrafts and had discovered Vim. Version 3.x ran on DOS as a 16-bit command-line app. I used it occasionally on NT. Then I discovered that Roger Knobbe had ported Vim to NT, but that it was pretty buggy. I fixed the bugs and submitted my fixes to Bram Moolenaar, Vim's author.

One thing led to another, and I became the Win32 guy for Vim 4.x. Console-mode Vim became rock solid on NT 4, but I never got it to the same level on Win95, due to inherent problems in the console APIs on Win9x. I also put together a proof-of-concept implementation of gvim 5.0 for Windows. At that point, I gave up active involvement in the development of Vim: I had moved back to Microsoft, I was starting to date Emma, and I was working on the Beginning ATL COM Programming book. Something had to give.

I continued using Viper for much of the time that I was developing Vim, because Vim was not then rich enough for my needs. After Vim got a scripting language (VimL) and syntax highlighting in version 5, I started using Vim more and more. I think it's been five years since I last used Emacs, and I never got beyond GNU Emacs 19.34.

Recently, I've stopped using Vim as my exclusive programming editor, and I've been alternating between Vim and Visual Studio plus Resharper, as I've started doing a lot of .NET development. But more on that some other time. This post is already too long.