I complained a week ago about my display driver going berserk. I blamed Windows Update, since it happened within hours of a pile of updates being installed. I upgraded to the latest beta NVidia drivers on Monday and it helped for a while, but by Wednesday, it was almost as bad again as it had been last Friday. It was infuriating and I was both entertaining and alarming my neighbors with my cursing.

Today was the last day of a very busy sprint for me and at last I had the time to dig into it. I opened up the case and took a look at both video cards—I have two dual-head cards connected to three monitors—and one of them had partially blown capacitors like those in the picture. I removed the bad card and did some graphics-intensive things for an hour, and the other card behaved flawlessly.

Oddly, until someone mentioned that it might be a hardware problem yesterday, it didn't occur to me, even though a video card blew in this machine last year. I came in one morning to find a black monitor, and when I pulled out that card, I found that some of the capacitors had popped right open with stuffing protruding.

On general principles, I had been meaning to repave this machine for a while. I've had it since December 2007 and it was still running the original installation of Vista. I booted from a DVD, reformatted my C: drive, and installed Windows 7 x64 RC1.

I finally have a 64-bit OS as my primary Windows desktop, so I'll actually be using the Win64 build of Vim that I maintain. My first impressions of Windows 7 on this machine are very favorable, but there's plenty more that I need to install before the machine has everything that I need.

I updated the Win64 binaries of Vim at vim-win3264 from Vim 7.2.000 to 7.2.182.

I'm amazed that the original binaries were downloaded over 11,000 times since last August.

On a StackOverflow question about favorite Vim plugins, I learned about Ack, a replacement for grep that's smarter about searching source trees.

Ack is written in Perl. The built-in :vimgrep is rather slow. It seems to have some Vim-specific overhead, such as creating swap files and executing BufRead autocmds. Ack is noticeably faster, though somewhat slower than GNU grep.

Which would you rather type to search a tree, ignoring the .svn and .git subtrees?

$ ack -i -l foobar
$ grep --exclude='*.svn*' --exclude='*.git*' -i -l -r foobar .

The ack takes 6 seconds to search 4500 files, while the grep completes in 2. This does not count the time that I spent trying to figure out the correct syntax and argument quoting for --exclude. The help says both --regexp=PATTERN and --exclude=PATTERN, but the latter is a glob (file wildcard pattern).

On Windows, I wrapped ack with pl2bat.

Exuberant Ctags is an essential complement to Vim: it generates an index of symbol names (tags) for a set of source files. In Vim, just place the cursor on a function name and type C-] to go to its definition.

Ctags works well for most of the languages that I deal with, but falls down badly on modern JavaScript. Its built-in parser simply doesn't handle declarations like these:

Sizzle.selectors.filters.animated = function(elem) { // ...
ajaxSetup: function( settings ) {

I came across Unbad's workaround earlier tonight. His code didn't work for me, so I hacked on it until it did:

--langdef=js
--langmap=js:.js
--regex-js=/([A-Za-z0-9._$]+)[ \t]*[:=][ \t]*\{/\1/,object/
--regex-js=/([A-Za-z0-9._$()]+)[ \t]*[:=][ \t]*function[ \t]*\(/\1/,function/
--regex-js=/function[ \t]+([A-Za-z0-9._$]+)[ \t]*\(([^)])\)/\1/,function/
--regex-js=/([A-Za-z0-9._$]+)[ \t]*[:=][ \t]*\[/\1/,array/
--regex-js=/([^= ]+)[ \t]*=[ \t]*[^"]'[^']*/\1/,string/
--regex-js=/([^= ]+)[ \t]*=[ \t]*[^']"[^"]*/\1/,string/

Simply add the above to ~/.ctags or $HOME/ctags.cnf.

Vim has had syntax highlighting since version 5.0 in 1998. It quickly became indispensable. It's hard to go back to looking at monochromatic source code after you've become accustomed to syntax highlighting.

The syntax highlighting is tied into Vim's support for colorschemes, which define colors for the fundamental syntax groups like Number, Comment, and String. The syntax highlighting for a particular language defines custom syntax groups for specific language features, such as cppExceptions or htmlEndTag,

The custom syntax groups are linked to the underlying fundamental syntax groups. Hence, if you change your colorscheme, your syntax highlighting is updated automatically.

The reStructuredText syntax highlighting in Vim 7.2 has some shortcomings, in my opinion. For example, *italic* shows up as italic in gVim, but in the same color as regular text, while **bold** shows up in a different color, but not bolded.

When you declare a syntax group, you can either link it to another gropu and pick up that's one color and fontstyle, or you can give it a concrete fontstyle and color. If you do that, then the syntax group won't change color when you change the colorscheme.

After much poking around, I found a way to set a syntax group's fontstyle and link it to another group's color: see hi def rstItalic and hi def rstBold below.

I also make use of certain Unicode characters in my reStructuredText source, such as endash and emdash, which are very hard to tell apart in a fixed-width font—even though an emdash (—) is twice as wide as an endash (–) in a proportional font. Worse, a non-breaking space is invisible and can't easily be distinguished from a normal space.

I provided custom highlighting for these Unicode characters and the various ‘curly’ “quotes”.

All of this goes into ~/.vim/syntax/rst.vim, which treats $VIMRUNTIME/syntax/rst.vim as a subroutine. I tried putting it into ~/.vim/after/syntax/rst.vim, which gets executed after $VIMRUNTIME/syntax/rst.vim completes, but then I can't provide non-overrideable definitions for rstEmphasis and rstStrongEmphasis.

function! s:SynFgColor(hlgrp)
    return synIDattr(synIDtrans(hlID(a:hlgrp)), 'fg')
endfun

function! s:SynBgColor(hlgrp)
    return synIDattr(synIDtrans(hlID(a:hlgrp)), 'bg')
endfun

syn match rstEnumeratedList /^\s*[0-9#]\{1,3}\.\s/
syn match rstBulletedList /^\s*[+*-]\s/
syn match rstNbsp /[\xA0]/
syn match rstEmDash /[\u2014]/
syn match rstUnicode /[\u2013\u2018\u2019\u201C\u201D]/ " – ‘ ’ “ ”

exec 'hi def rstBold    term=bold cterm=bold gui=bold guifg=' . s:SynFgColor('PreProc')
exec 'hi def rstItalic  term=italic cterm=italic gui=italic guifg=' . s:SynFgColor('Statement')
exec 'hi def rstNbsp    gui=underline guibg=' . s:SynBgColor('ErrorMsg')
exec 'hi def rstEmDash  gui=bold guifg=' . s:SynFgColor('Title') . ' guibg='. s:SynBgColor('Folded')
exec 'hi def rstUnicode guifg=' . s:SynFgColor('Number')

hi link rstEmphasis       rstItalic
hi link rstStrongEmphasis rstBold
hi link rstEnumeratedList Operator
hi link rstBulletedList   Operator

source $VIMRUNTIME/syntax/rst.vim

syn cluster rstCruft                contains=rstEmphasis,rstStrongEmphasis,
      \ rstInterpretedText,rstInlineLiteral,rstSubstitutionReference,
      \ rstInlineInternalTargets,rstFootnoteReference,rstHyperlinkReference,
      \ rstNbsp,rstEmDash,rstUnicode

I use or participate in a handful of wikis hosted at PBwiki. A year ago, I wrote a PBwiki syntax highlighting plugin for Vim, modeled after the ones that I put together for the FlexWiki and SocialText wikis. Essentially, paste the wikitext into Vim, get syntax highlighting, edit the text, then paste it back into the multiline textbox. I find the WYSIWYG editors annoying.

PBwiki is forcing all wikis to switch over to v2.0 by March 9th. The good news is that the upgrade is painless and reliable. They offer new features, such as an improved editor, better access control, and a new look.

The bad news is that for cranks like me, there's no longer an advanced editor and wikitext. I can use the WYSIWYG editor or I can switch it to HTML source mode. Ick!

So how do I go from the Project Gutenberg etext to LaTeX?

Here's the Gutenberg text for the pictured fragment:

(BLOOM'S WEATHER. A SUNBURST APPEARS IN THE NORTHWEST.)

THE BISHOP OF DOWN AND CONNOR: I here present your undoubted emperor-
president and king-chairman, the most serene and potent and very puissant
ruler of this realm. God save Leopold the First!

ALL: God save Leopold the First!

BLOOM: (IN DALMATIC AND PURPLE MANTLE, TO THE BISHOP OF DOWN AND CONNOR,
WITH DIGNITY) Thanks, somewhat eminent sir.

WILLIAM, ARCHBISHOP OF ARMAGH: (IN PURPLE STOCK AND SHOVEL HAT) Will you
to your power cause law and mercy to be executed in all your judgments in
Ireland and territories thereunto belonging?

BLOOM: (PLACING HIS RIGHT HAND ON HIS TESTICLES, SWEARS) So may the
Creator deal with me. All this I promise to do.

MICHAEL, ARCHBISHOP OF ARMAGH: (POURS A CRUSE OF HAIROIL OVER BLOOM'S
HEAD) GAUDIUM MAGNUM ANNUNTIO VOBIS. HABEMUS CARNEFICEM. Leopold,
Patrick, Andrew, David, George, be thou anointed!

The Gutenberg transcriber has converted all italics to uppercase. All accents on letters have been lost (there were none in this fragment).

Here's the corresponding LaTeX that I derived from the above:

\stage{(Bloom's weather.
A sunburst appears in the northwest.)}

\DownConnor:
\gab{1470}
I here present your undoubted emperor-president and king-chairman,
the most serene and potent and very puissant ruler of this realm.
God save Leopold the First!

\All:
God save Leopold the First!

\Bloom:
\stage{(in dalmatic and purple mantle,
to the bishop of Down and Connor, with dignity)}
Thanks, somewhat eminent sir.

\WillArmagh:
\stage{(in purple stock and shovel hat)}
\gab{1480}
Will you to your power cause law and mercy to be executed
in all your judgments in Ireland and territories thereunto belonging?

\Bloom:
\stage{(placing his right hand on his testicles, swears)}
So may the Creator deal with me.
All this I promise to do.

\MikeArmagh:
\stage{(pours a cruse of hairoil over Bloom's head)}
\latin{Gaudium magnum annuntio vobis.
Habemus carneficem.}
Leopold, Patrick, Andrew, David, George, be thou anointed!

I could simply have used \em to get italics, but I'm a big believer in semantic markup, so I wrote a set of custom macros, like \stage and \latin. The name macros, like \Bloom and \All, are defined in terms of the \role macro. The \gab macro lists the line number in the Gabler edition of Ulysses. It's useful for looking up reference works and it would have been hard to do in reStructuredText.

\newcommand{\stage}[1]{\emph{#1}}
\newcommand{\role}[1]{{\textsc{#1}}}
\newcommand{\Bloom}{\role{Bloom}}
\newcommand{\gab}[1]{\marginpar{#1}}

I used Vim to massage the text.

• For my own sanity, I have broken each clause onto a separate line. Much of this can be done by substituting a newline after every period and right parenthesis. The other breaks require manual splitting and joining of lines.
• Transforming BLOOM: into \Bloom: is a trivial text substitution, :%s/^BLOOM: /\\Bloom:\r/
• All the uppercase text has been converted to mixed case. Much of it needs to be bracketed by \stage{} in this chapter. The rest needs to be treated as \latin{}, \hebrew{}, \french{}, and so on.

I used the following Vim macro to bracket the visual selection with \stage{}.

" ;s => SELECTION -> \stage{selection}
vnoremap <buffer> <silent> ;s u`>a}<Esc>`<i\stage{<Esc>

Breaking it down, since that looks like line noise.

It's necessary to append to the end of the selection first. Were I to first insert at the beginning, the append would happen seven characters (len('\stage{')) too early. (I picked this trick up from Christian Robinson's HTML macros.) Then I have to go back and convert a few characters to uppercase with the ~ operator.

This workflow isn't for everyone and it would be difficult if I had to hand it off to someone else. Most non-geeks would prefer to use a WYSIWYG tool like Word. I loathe Word and I want the control.

All of this is somewhat tedious, since even with useful Vim macros taking care of many of the changes, I still have to make manual tweaks on almost every line. But this is also a virtue, as it makes me intimately familiar with the text.

The hardest task—at least for me—is making the dramaturgical decisions. Usually, it can be hard to decide exactly to whom a particular line should be ascribed—making sense of Bloom's interior monologue, for example, or splitting a long stretch of narrative between several narrators. This year's chapter is written in the form of a play, so that particular problem is gone. Last year was the first time we abridged a chapter. This year, we have to reduce 60,000 words to 15–20,000 words. Whether that's by breaking the chapter into two or more readings, or by deep, deep cuts, I have yet to decide. And that's where the line-by-line familiarity is helpful.

Perusing Eric S. Raymond's blog recently, I noticed his claim that as a one-time maintainer of GIFLIB, just about every cellphone and browser has some of his software running in it.

That got me thinking about my own reach and where software that I've contributed to can be found.

‘Oh that a man's reach should exceed his grasp, or what's a Heaven for?’

—Robert Browning

I spent seven years on the IIS (Internet Information Services) development team at Microsoft. By any measure, that's a successful product, running one-third of all websites. There are over 100 million registered websites. Many of them are parked and many others see negligible volume, but that's millions, perhaps tens of millions of Windows Server boxes.

Two of those years were spent working on http.sys, the kernel-mode driver that underpins IIS 6. Http.sys was back-ported to Windows XP and released as part of XP SP2 (though IIS 6 never was), and it's an integral part of all later versions of Windows. That's hundreds of millions of Windows boxes.

And then there's Vim. I wrote much of the Win32-specific code–and all the Win64-specific code–but I also made contributions to the core code. Vim has long been the standard implementation of vi in most Linux distributions. And Vim is installed on all recent versions of Mac OS X.

So, I can claim Windows and Linux and Mac–though few cellphones. Not too shabby.

(I'm also one of a small number of people thanked in ESR's Jargon File; in my case, for TeX arcana and painstaking proofreading.)

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:

 
 
        processorArchitecture="X86"
     version="6.2.0.0"
     type="win32"
     name="Vim"
   />
   Vi Improved - A Text Editor
   
     
                type="win32"
         name="Microsoft.Windows.Common-Controls"
         version="6.0.0.0"
         publicKeyToken="6595b64144ccf1df"
         language="*"
         processorArchitecture="X86"
       />
     
   
 

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.