I want to thank everyone who replied to my last post and told me everything that was wrong with Haml error messages. I think I’ve fixed everything that was mentioned there, but if something else comes up please let me know.

I was surprised to learn that most of the problems were with line number inaccuracies and the error not managing to bubble up through Rails properly. I was going to do a similar post for Sass, but since it doesn’t seem to have the same issues, I think I’ll skip it.

Instead, I thought we could do some brainstorming. Haml’s been missing an important bit of functionality for a while now. Although it’s powerful enough to express almost everything you can with plain XHTML, Haml isn’t good at not producing whitespace.

I love it when people rant about Haml and Sass. As wonderful as positive feedback is (and I love that, too), criticism is golden. Hearing what people hate about these programs is hands-down the best way to figure out how to improve them.

For example, people hated that Haml was so much slower than ERB. It’s not any more¹. People hated that it was so annoying to format whitespace-sensitive HTML elements like textarea and pre. This will “just work” as of the next major release.

Unfortunately, there’s one major issue I haven’t been able to fix. I’ve heard over and over again on blog posts and Twitter that people just can’t understand Haml’s and Sass’s error messages.

I was using Chris Wanstrath’s cheat the other day, seeing if there were any cool git features I was missing out on (did you know you can color the output?). If you haven’t come across it yet, cheat is a nice little Ruby utility that displays “cheat sheets”— user-generated pages of text that serve as miniature reference manuals.

Unfortunately, some of these cheat sheets can get pretty long. The git one is 228 lines. Some of the text went off the top of my terminal. I sighed and typed in cheat git | less, thinking once again how nice it would be if more programs followed git’s example and automatically paged their output.

Although git’s not usually held up as a paragon of usability¹, there are a few places where it shines. My favorite is how it’ll run less on its output when the output is too big to fit on my terminal screen. Then I can easily scroll and search through the text.

Since I had a bit of time with nothing urgent to do, I decided to take a crack at making cheat page like git. Two and a half hours later, after digging through git’s source, getting help from the good folks in #git and #ruby-lang on Freenode, and receiving tons of bug fixes from Kevin Ballard, I got it to work.

One of my favorite features of wmii is tags¹. These allow you to divide up windows into categories based on whatever you want.

The basic idea is really simple. Each window has a set of strings associated with it, called its “tags.” At any given moment, you are “viewing” a single tag. This means that only windows with that tag are displayed.

What’s more, each tag has a certain configuration of windows. This means that I can have Firefox in the upper-left corner for my programming tag but taking up the whole screen for my web tag.

A few months ago, I started playing around with the ruby-wmii codebase, trying to get it to work with the newest version of wmii. I eventually succeeded, but that’s not what this post is about.

Mauricio Ferndandez, the awesome guy who originally created ruby-wmii, uses darcs for most of his projects, ruby-wmii included. Since I wanted to muck with ruby-wmii and send patches back, I had to give it a try as well.

Until that point, I’d never really used any revision control system other than Subversion. I’d checked out some stuff from CVS, but never made a commit to anything that used it. Not that it’s all that different from Subversion anyway.

I’ve been playing around with distributed revision control recently. I have another post in the works all about that, so I’ll skip over the details for now.

The upshot of my adventures is that I’m pretty much convinced that there’s almost no reason to use a client-server system rather than a distributed one¹. Distributed systems have all of the capabilities of client-server systems, and more besides.

So you can imagine my pleasure when Hampton IMed me a few days ago saying “What do you think about moving Haml to Git?” I replied that I thought that was a fantastic idea.