#stumpwm

Window management is exactly like tmux except all of the chords are different.

Configuration is exactly like emacs except all of the variables are different.

As a horrible workaround, since there are some apps I occasionally use like the Dell BMC remote console Java app, I run:

Xephyr as a nested X server : Xephyr :1

Set the DISPLAY variable to point at this in a single xterm : export DISPLAY=:1.0

Run metacity in this terminal to get the GNOME window manager on that display : metacity &

Now run the problematic app. E.g. javasw jviewer.jnlp

It seems that there is a bug with the current Debian unstable asdf which causes Lisp compilers to fail to find the installed components if the XDG_DATA_DIRS variable is not set. This variable is set if you use Gnome, but when not set asdf fails to use a default setting for where to look for systems or source and so doesn't find anything at all!

This has been reported as Debian bug 723977 and a fix is in testing so hopefully it will be updated soon.

As a workaround, you can add the following to a file which is included by the common-lisp-controller, such as /home/username/.config/common-lisp/source-registry.conf.d/system.conf (anything in the ~/.config/common-lisp/source-registry.conf.d directory is included, so you can have multiple separate files in here), containing:

(:tree "/usr/share/common-lisp/source/")

..and this will allow all lisp compilers/interpreters to find the installed packages. It used to be that symlinks were required from /usr/share/common-lisp/systems/ into the individual package directories, but this has been deprecated in favour of it searching the source tree.

It's been a long time since I did anything with Lisp, and I came back:

Ok so it's not much, but I got this feeling afterwords of actually doing something.

This, like my previous experiences with Common Lisp has been to play around with the configuration of my window manager (StumpWM.) There's evidence in my config of more impressive hacking, but it's been a while and I'm better at programming now in general than was the last time I dabbled.

Anyway.

This got me thinking about how we learn to program and the common pedagogy associated with programming.

The general consensus is that it's important to get prospective programmers to do something, anything, very quickly. As a result, learning instructions on programming start with an obligatory "Hello World" program.

Except, that getting systems to output "Hello World" isn't terribly interesting or useful. It's also not a terribly good introduction to doing things with software, and in most cases doesn't convey a sense of how programs expressed in a given language work.

Which isn't to say that it's bad, but that it's not a good starting point. Better I think to say "here's the second example," and then say "if you want to see the 'hello world,' [click here]." Our introductory examples need to include:

a code block (e.g. function, etc.)

variable assignment.

a data structure (if applicable, maps and lists of some.)

a conditional statement.

capturing information/state from something external to the program.

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.

finally got stump working perfectly.

urxvt running zsh, as you can see from the archbey command; pseudo-transparency.

oh-my-zsh theme is "jonathan".