Skip to main content
  1. Posts/

I am leaving StumpWM and X11

·517 words·3 mins·
ebeem
Author
ebeem
FOSS Enthusiast & Indie Game Developer

Lisp-Based Tools

If you have spent any significant time in the world of Lisp-based tools, you know that once you invest in tweaking them, you simply can't quit. I have spent years living in Emacs and StumpWM, addicted to the idea that my environment shouldn't just be "configurable," but truly extensible.

In StumpWM and EXWM, the line between "user" and "developer" is paper-thin. If you want a new feature, you don’t submit a feature request; you open a REPL and redefine a function on the fly. However, with X11 nearing its end-of-life and the beauty of modern Hyprland setups I am seeing, I feel it's time to begin my transition to Wayland.

Emacs as a Window Manager

I experimented with EXWM (the Emacs X Window Manager), and initially, I was shocked, I couldn't believe such a feat was even possible. But then again, it’s Emacs; everything is possible. However, the experience highlighted a critical flaw: if Emacs froze or crashed, my entire session vanished.

I've come to realize that I don't want to assign Emacs heavy-duty system tasks like window management. I prefer using Emacs as the interface between myself and other specialized utilities. Much like how dired can act as a frontend for ls, I believe a window manager should be assisted by a dedicated compositor written in a systems language like C, Rust, or Zig. Entrusting the entire desktop session to a single-threaded Lisp interpreter is, in my view, a bottleneck for stability.

Creating a Lisp-Based Scripting Environment

I believe a window manager should apply the "Emacs Principle" because everyone's workflow is unique. I have seen people using Emacs setups so personalized that I couldn't even tell it was Emacs.

In my case, I have a specific workflow requirement: extending workspaces across multiple monitors. Assuming I have 2 monitors ot#1 and ot#2. I want each to have its dedicated workspaces, let's say each will have 3 workspaces. Whenever the workspace of ot#1 changes to workspace number 2, the workspace of ot#2 should also change to workspace number 2 (syncing).

  |           ws#1           |           ws#2           |
  |-----------------------------------------------------|
  | ws#1-1 & ws#1-2 & ws#1-3 | ws#2-1 & ws#2-2 & ws#2-3 |

I tried implementing this in Sway and Hyprland using their standard configuration languages, but I hit a wall. I could bind a key to switch multiple workspaces simultaneously, which worked temporarily, until a window stole focus or an unexpected workspace change occurred. This inevitably caused the monitors to get out of sync.

To solve this properly, I can't just rely on simple keybindings; I need a persistent event listener. I need the environment to watch for workspace changes and programmatically sync the other monitors accordingly. This requires a level of logic that static config files simply cannot handle.

The Way Forward

I need a compositor that is stable but provides a "hook" for high-level logic preferably with a lisp-based language like guile. My next step is to experiment with a both Sway and Hyprland to see how far I can push the implementation of custom window management logic without sacrificing the stability of the underlying Wayland compositor.