Skip to content

monads, menus, and mercurial

Recently I switched from the tiling window manager ion3 to a new window manager: xmonad. xmonad is written in Haskell, has a tiny and malleable code base (500 lines), and is easy to extend (if you know Haskell!).

One of the reasons that xmonad is so small is that it leaves some window manager features to external programs. For example, it doesn’t have any sort of menu. Most xmonad users use dmenu to provide a program launcher. (I also use it to run internal xmonad commands with my XMonadContrib.Commands module.)

dmenu is originally by Anselm R. Garbe, author of the window managers dwm and wmii. He follows strict anti-bloat principles and endeavors to keep his programs free of extraneous features. This is a respectable goal. On the other hand, there are several patches that multiple users have found useful that are not included in dmenu: Xinerama support, a history feature, and so on.

dmenu is maintained in the Mercurial distributed version control system. This makes it trivial for me to maintain my own version of dmenu, synced with upstream changes, that includes these extra features. It’s even easy for me to share this with the world. (I’d like to think of this as an “extra features edition” rather than as a “fork”.)

You can check out my version with Mercurial:

hg clone http://www.davidglasser.net/hg/dmenu/

or just grab a tarball of the latest version.

On a related note, I’ve been very happy with Mercurial. Its user interface is very nice, the underlying principles are sound, and the work-in-progress book by Bryan O’Sullivan is well-written and helpful. xmonad uses the distributed version control system darcs, and I tried to do similar tasks (keeping my local config in my personal repository while syncing with upstream) in darcs. While darcs has many interesting ideas, I ran into the serious performance problems almost immediately; and because darcs doesn’t really have any idea of a “changeset identifier” other than the log message, it’s pretty hard to use the command line to find out about various patches. Mercurial, on the other hand, was a breeze. There are certainly things I prefer about Subversion (documented internals with a stable API being the most obvious), but I should definitely experiment more with Mercurial (if for no other reason than to learn lessons that can be applied to Subversion and svk).

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*