There's a Vim plugin I've had my eyes on for a while: AutoClose, by Thiago Alves. It's a rather nifty plugin that will complete open-close character pairs, such as quotes, parenthesis and braces, when typing in insert mode.

That is, if you type a (, AutoClose will insert the matching ) right away, though it is smart enough to not insert it if it was already there and things like that.

This is a rather nice feature that I missed from editors like Eclipse and Netbeans when working in Vim. The reason I wasn't using AutoClose sooner was that it had one annoying issue: Sometimes, when inserting an open character as the first character in a line, it would de-indent that line all the way to column 0.

This seemed to be somehow related to my use of a US-International keyboard layout, so I didn't pay much attention to it and decided to just wait it out and keep an eye on it.

Thiago recently updated his plugin and I'm happy to say that this problem seems to have gone away completely. I'm now keeping AutoClose enabled and seems to be working pretty well for me. Sweet!

I don't really know much about fonts, but I still love them; particularly monospaced fonts for writing code. I've tried a lot of monospace fonts over the years, including two of my past favorites: Consolas and, more recently, DejaVu Sans Mono. Great fonts both.

However, I'm a huge fan of Damien Guard's Envy Code R font. It's an absolutely beautiful font all around and Damien has put a lot of effort into making it very readable on screen with good hinting. It just looks gorgeous on Visual Studio, particularly thanks to the italics-as-bold trick Damien came up with. (Which reminds me that I really owe Damien at least a few beers if we ever meet!)

Unfortunately, every time I tried to use Envy Code R  on one of my Ubuntu machines, the result was not what I expected; for whatever reason it just didn't look as good as it did on Windows. DejaVu Sans Mono, however, looked good on both platforms, so I was using that as my default font for GVim.

Here's how Envy Code R looked like in GVim under Ubuntu, contrasted against the Windows version (with ClearType enabled):

Ubuntu	Windows

Both images were taken using the Envy Code R at size 13. You should be able to spot several differences right away:

• The text in normal weight (non-bold) looks a bit thinner on Ubuntu
• Some characters really show a significant difference in how they are rendered. The 'm' in particular looks very thin and aligned too much to the left.
• The quotes are a lot harder to see, especially in comments where there is less contrast between the foreground and background colors.

I pinged Damien to ask if he knew what this might be related to. He pointed out that every Operating System had a different way of rendering fonts so it was natural for them to look a bit different on each one. I was, of course, aware of this and even remembered that Jeff Atwood had touched on this topic in the past. Damien also suggested I verified that my Ubuntu installation had sub-pixel hinting enabled.

I went ahead and checked it one more time, and the font settings clearly showed sub-pixel rendering and full hinting enabled:

Damien's comment regarding the settings made me remember something: I use Xubuntu, which uses XFCE as the desktop manager. However, I believe GVim is written on top of GTK+ (Gnome) and wondered if this had anything to do with it.

I went ahead and checked the Gnome settings just in case, and they did not have sub-pixel smoothing enabled; only the "best appearance" setting was checked. So I went ahead and changed the Gnome settings as well, restarted the machine (just in case) and.... no dice. The font still didn't look right.

Solving the Puzzle

After a couple of days of tweaking options here and there, I finally found a combination of settings that allowed Envy Code R to be rendered on Ubuntu a lot better for my taste.

Here's the catch: I had to enable sub-pixel hinting (setting it to RGB), but change the hinting setting from Full to Slight. This makes some fonts look a little bit more fuzzy, but it makes both Envy Code and DejaVu Sans Mono look great (or at least a heck of a lot better), which is what I wanted all along:

Turns out that the XFCE vs. Gnome thing wasn't really important after all. In the end, here's how I got it to work:

1. Open the XFCE Settings Manager, and then launch the User Interface applet.
2. Make sure that the "Use Hinting" option is set to "Slight" and that the "Use sub-pixel hinting" option is set to "RGB" (or whatever is appropriate to your screen).
3. If you have any GVim instances open (or other GTK+ based apps, like gnome-terminal), then close and restart them. Otherwise, they won't completely pick up the changed settings.

If you're using Gnome as your desktop, you can get the same using the Gnome appearance applet:

1. Run the Gnome settings UI by launching the gnome-appearance-properties application from a terminal window. I don't remember where this is located in the UI, but should be easy to get to.
2. Go to the Fonts tab and then click the Details Button. In here, set the Smoothing option to "Subpixel (LCDs)" and the Hinting option to "Slight". Make sure the subpixel order option matches your screen.
   
   
3. Apply all the settings.

Now I can enjoy Envy Code R on Linux as well as Windows .

Ubuntu, Vim, Fonts

I've mentioned in the past some of the color scheme scripts that I've used to make Vim nicer, and there are some really nice ones. However, I was growing tired of them lately. I looked around the Vim site trying to find something better but came up empty handed.

Around that time I ran into Hamish Macpherson's blog, and noticed he was using a really nice color scheme on his code screenshots, and then read in one of his comments that it was a slightly modified version of the monokai theme for TextMate.

I decided to try porting them to Vim, though it's a very loose port. I've been using and tweaking it for a few weeks now, but I'm pretty satisfied with it. I decided to post it here just in case anyone else is interested.

There are two variations to the theme; which one is used can be controlled by setting the g:molokai_original variable in your .vimrc file.

The default option (molokai_original == 0) uses the dark gray background variation similar to Hamish' version, and looks like this:

With molokai_original == 1, the script will use the original monokai colors, and looks like this:

You can get the script from my dotfiles repository on github; where you'll find always the most recent version. Enjoy!

Vim, monokai

I've mentioned in the past that I've experimented with a number of different options for styling and syntax highlighting code snippets on this weblog, with varying degrees of success.

For a few months I've been using CSS-based syntax highlighting based on the code generated by Vim's :TOhtml command, and it's been working out pretty well. It means that my RSS feed doesn't have any color, but at least the code itself is correctly formatted.

The part I didn't enjoy too much about :TOhtml, however, was that it would only generate the minimum number of style rules it need to highlight the piece of code it was generating the HTML for. This works fine in many scenarios, but it was annoying for me because it meant I needed to continually update my site code.css file as new rules were generated for new snippets that I didn't have in there before.

So what I really wanted was a way to convert the Vim colorscheme of my choice into a CSS useful for my site. Naturally, I turned to PowerShell and came up with convert-vim2css.ps1:

It's not very fancy and it only supports GVim schemes, but that's enough for me and does the trick for now.

Vim, PowerShell

A few days ago the second beta release of Vim 7.2 came out and I decided to give it a try. Seems to be working great so far, and I'm pretty excited about this release for a couple of reasons:

1. Performance Improvements: Under Windows, Vim 7.1 had some  performance problems, particularly related to redrawing the screen. This was particularly noticeable when scrolling large windows with syntax highlighted code with the mouse wheel, and when redrawing the [omni-] completion menu.
   The former feels much snappier, even with long lines, while the second appears to be fixed altogether!
2. Floating Point support: I don't create much Vim scripts myself, but I'm excited by some of the possibilities this opens up for scripts I may use. One example of this is Yukihiro Nakadaira's HueRotation script.

Vim