I’ve just about finished working on the linuxest thing I’ve done, and I thought I’d write about it, if only to distract from “hey tumblr I bought a book from people with more ink than skin, am I cool now”. Short version: I switched window managers again.

Brief rundown of the software involved: A windowing system is something that mediates windowing, or indeed any graphics, for user programs, on behalf of the operating system. If you’ve never heard the term, you may be used to Windows, where the windowing system is strongly integrated into the operating system. On Linux, the most common windowing system is X, usually as implemented by X.org. There are a few alternatives, such as Wayland, but they don’t have quite the market share just yet.

On top of the windowing system is the window manager. This is a program that handles actually doing things with the windows, such as moving them, closing them, etc. In Windows, again, this is integrated with the OS, but on Linux there are quite a few options, such as Metacity or KWin. These programs have their own characteristics, design goals, interfaces, etc. As in many parts of Linux, this results in a great degree of freedom for the informed user, and a lot of confusing usability problems for people who don’t want to read thirty year old software manuals. Luckily (unluckily) for me, I’m the kind of person who does that for fun.

I started caring about window managers when my Linux distribution, Ubuntu, came out with a thing called Unity. And since Unity isn’t just a window manager but a whole desktop experience, and an overhaul of what had been there before.

Like a lot of people (there’s this whole “controversy” about it, it’s pretty funny to look into if you like watching people get upset about weird things), I didn’t like it much. Despite being designed for netbooks, it was slow and memory-hungry, and didn’t really seem appealing to me beyond its glitziness

I switched back to the regular GNOME environment, but continued to find problems and whine about them on IRC. Eventually, IllFlower (who is more up on these things than I will ever be) suggested, probably jokingly, that I might prefer a minimalistic window manager, such as awesome. I went ahead and installed it, and to my surprise, he was right - it booted up in less than a second, I could tab between programs faster, and it was unobtrusive.

But then I got thinking that maybe I should roll my own system that would be Exactly What I Wanted. Awesome has a lot of window-arranging stuff (e.g. having two windows on screen at once) that I never used, finding it more convenient to tab between several running programs, for example. (yes, this is the sort of thing some people actually think about sometimes.) So I tried out a window manager written in the programming language I’m mostly comfortable with (CL), StumpWM. I don’t know why it’s called that; isn’t it a terrible name?

Since I was without internet for a while, I figured it was a decent time to get things working as I liked. StumpWM isn’t a popular window manager by any stretch of the imagination, which means it’s not very supported, it’s ugly (X fonts! Really!), and it’s nontrivial to integrate with everything else on my system. The rest of this post is why I think I’ll be using it for a while anyway.

First off, it has a lot to do with CL. CL is in a lot of ways very interactive. Of course a lot of using it is via a read-eval-print loop, like Python et al., but in addition to that, most CL programmers use swank, which integrates an editor (usually emacs, though there’s also slimv for vim) with a running Lisp process. This means that in addition to sending individual lines to be evaluated, you can also, for example, select part of your source code, and tell the Lisp to compile and run it. This has its disadvantages, chiefly that it’s easy to get your source code and your program out of sync if you’re not paying attention, but overall it’s a very nice way to code. Once I got a swank server running (which unfortunately took a lot of flailing around…), I became able to vet what I was doing as I went, and modify StumpWM’s behavior without restarting it. So that was cool.

This also led to me writing my first emacs function, a simple thing to connect to the StumpWM program. Here it is, for the hell of it:

(defun stumpwm-read-swank-port ()
  "Read the value of stumpwm's swank port, and then delete the file."
  (with-temp-buffer
    (insert-file-contents "/tmp/stumpwm-swank")
    (delete-file "/tmp/stumpwm-swank")
    (goto-char (point-min))
    (let ((port (read (current-buffer))))
      (assert (integerp port))
      port)))

As you can see, I didn’t really know what I was doing. I did find out that both emacs’ and elisp’s info pages were installed on my system, which is helpful, more helpful than having to browse to the GNU website’s at least.

Secondly, as a few people have noted, StumpWM is laid out like Emacs. This means, of course, bizarre key combinations (for example, “jump to the 3rd window” is by default bound to pressing ctrl-t then ctrl-3), but more importantly, there are keys to see what a given key means, or what a given command does, or to rebind commands to key combinations that are more your style. And you can do this all programmatically. This lends it to control freaks such as myself. For example, I’ve bound super-e, -t, -f, -c, and -i (where “super” is the otherwise unused Windows key) to launch the applications I use most often (emacs, terminal, firefox, chromium, irssi), or jump to them if they’re already running. This is basically what I was doing in awesome, practically speaking, but now the intent of the program fits more with my intent, since of course, I wrote the program.

My original intent was to write a new window manager, and I’m still looking into that. StumpWM’s interactive programmability helps, and I can look up how its interactions with X for examples. In addition I can interact with X itself through the CLX library*, the CL equivalent to Xlib. Being able to quickly test what some code does really helps me learn. For example if I want to see what information an X window has, I can just do (xlib:window-foo stumpwm::(window-xwin (current-window))) to get whatever foo is from my emacs window.

I hope this doesn’t come off as an advertisement; I’ve just had a lot of fun exploring things and wanted to write about it.

*note for people who already knew what Xlib was: Did you know that CLX was actually written around the same time, and some X design stuff is actually due to Lisp? XIDs being 29 bits (for tag) rather than 32, is the main thing, which isn’t exactly flattering, but still, I had had no idea.