I recently decided to re-adopt a piece of Linux tooling that used to be an everyday bit of equipage when I worked as a professional programmer. From the outside looking in, it is a bit of a curiosity: the window manager. The venerable X Window system, the long-time standard on Linux and BSD, has existed since the 80s. Window managers intercept actions and stateful operations passing between the X server and the corresponding client, making its own decisions about how to position and draw windows.

On modern, mainstream operating systems, various features are available to average computer users, where windows can be swapped through using a key sequence like <ALT>-<TAB> or <CMD>-<TAB>. As for me, a core limitation of these tools has always been their ability to position the windows. Even on common flavors of Linux like Ubuntu and Fedora, the ability to snap panes to different parts of the screen feels woefully limited and clunky to me.

So I shopped around. My initial presumption, as a user of Fedora, is that a Wayland-based window manager would be obligatory. Under this erroneous assumption, I thought I would have to run an X tiling window manager using XWayland, the bridge between the two. A quick read on the internet disabused me of this notion, fortunately, as it would have been tantamount to running one window manager inside another, with probably catastrophic consequences for performance, or at the least some extremely bizarre graphics behavior.

I am a devotee of Emacs. I use it for almost everything. I already knew about Emacs X Window Manager (EXWM), but I was initially somewhat scared off because at the time, I wasn't much of a skilled Emacs user, and the thought of being limited in the basic functionality of my computer by that weakness put me off. But as my confidence with and knowledge of Emacs has grown, I decided to give it a go.

So, I configured EXWM as described in the wiki and got it running. But then, it didn't work at all. I could start the X session, and the Emacs frame would appear, but it would only occupy a fraction of an otherwise blank screen. If I started another program, using the M-& command, it would stack on top of the fragmented Emacs window. Then, if I killed that process, the display would be redrawn, but only in part. The Emacs window would come back to the top, and a frozen picture of the closed app would appear behind it.

This isn't useable at all, so I went hunting on the internet for answers. Being that it looked like funky graphics issues to me, my initial hunch was to search the system journal, possibly for glaring errors like missing Xorg drivers or kernel modules. Indeed, I was missing some drivers, as well as a few X libraries, but installing these had no effect on the apparent issue.

The following day¹ I tried something new. I thought, why not install a different window manager under X, and see how it behaves? I picked StumpWM, because I am a Lisp enjoyer. And sure enough, after following the directions, it worked without any problems. But, here's the punchline: StumpWM proved to be a fortuitous choice, due to its Emacs-specific orientation. When I started Emacs with its preconfigured C-c C-e keystroke, I received a prophetic and much welcome warning: I had been using, ignorantly, an Emacs version that uses the Gnome Toolkit (GTK) to display the window. As it turns out, this doesn't play nicely with X. It furthermore gave me the suggestion to use emacs-lucid instead.

So, I popped open a terminal and followed this advice: I uninstalled emacs-gtk and replaced it with emacs-lucid. With bated breath I ended my X session², and switched over to EXWM in the SDDM login screen. Sure enough, things just started working.