back

by Philpax·9mo ago·view on hn ↗
Configuring your WM in Haskell seems fun, but I suspect "fun" is the primary motivator, not any kind of practical reason.

Type-checking keybindings is cute, but you're going to discover that the keybinding doesn't work when you go to use it, so how much time are you really saving? That's not helped by the fact that many WMs/compositors have validators for their configs, so you're getting much of the same benefit with much less trouble.

For reference, Niri's config is very approachable: https://github.com/YaLTeR/niri/blob/main/resources/default-c...

4 comments
Apart from the Haskell fun, xmonad is really really good. Especially how it handles workspaces on multiple monitors. By default, each monitor has one workspace. Not one workspace for ALL monitors.

So if your side screen has say documentation open, and you switch on your main screen from terminal to editor, only the main screen changes. The side screen stays untouched. Some people prefer it, some hate it. But it's good that xmonad offers it. It also has hot reloading of the config, which is also nice.

Sure, Niri's config is approachable, but is it hackable? It only offers what Niri offers, right? You can't extend its functionality by config alone.

That is where XMonad and others shine. Sure, they might not be for the "I don't wanna spend time configuring my WM to death" crowd (and I mean absolutely no derision in that. We all have different rabbit holes we want to customize to oblivion), but Xmonad or Stumpwm etc allow for those shenanigans, and I myself am very very happy to have those.

Long story short, it's not all 100% about the type safety, it's also a lot about the extensibility of it.

Niri is nice, not mocking it. But infinite scrolling is not everyone's jam. Some others might even question the choice of KDL instead of JSON without any clear benifit.

Whatever you prefer and if it works for you, great. That's why we have choices ^^

I'm not a Niri stan by any means - I only switched to it the other week, and was using sway/i3 before then - but I suspect that most alternatives have answers to these, too.

> Especially how it handles workspaces on multiple monitors. By default, each monitor has one workspace. Not one workspace for ALL monitors.

I'm pretty sure this is the case for most tiling WMs; it's definitely the case for Niri (https://github.com/YaLTeR/niri/wiki/Workspaces), and I'm pretty sure it's the case for sway.

> It also has hot reloading of the config, which is also nice.

Niri will reload your config on save; Sway requires a keybind, but no restart.

> Sure, Niri's config is approachable, but is it hackable? It only offers what Niri offers, right? You can't extend its functionality by config alone.

Most Wayland compositors offer that extensibility through messaging; you would send messages to Niri or Sway through scripts to achieve custom behaviour. I do miss having scripting built-in in AwesomeWM, but it hasn't been too much of an issue for me in practice.

> Niri is nice, not mocking it. But infinite scrolling is not everyone's jam. Some others might even question the choice of KDL instead of JSON without any clear benifit.

I brought Niri up as an example, but the general point I was trying to make is that the other tiling compositors/WMs out there offer similar solutions that get you to the same place, but through easier means. As for KDL, I think it would be difficult to argue that JSON is easier for humans to edit than KDL :p

> Whatever you prefer and if it works for you, great. That's why we have choices ^^

By all means! I'm not denigrating XMonad or such here; it's more that I think it's probably not the right choice for most people in the market, as there are alternative solutions that are likely to get you to the same place with less friction.

Trust me, the majority of tiling WMs has on workspace for ALL monitors combined. The percentage of WMs treating every monitor as a separate unit is smaller.

And sure, you can send message and commands to Niri via IPC, but that is very very different from say XMonad or StumpWM where you can actually override or alter functionality within the config instead of having to change the original source code.

That I'd say is the very definition of hackable. When you can actually just throw stuff into your config to change core behavior.

> it's definitely the case for Niri

No, it doesn't seem that way. The Niri manual says each monitor has an independent set of workspaces. In XMonad there is one shared set for all monitors, but each monitor independently shows one of those workspaces.

(If the user tries to show on monitor A the workspace currently visible on monitor B the two monitors swap their workspaces.)

To pile on, if I wanted an actual language to do config work I would prefer bash for simple scripting. I started using riverwm and I love its take on config. Use whatever language you want because configuring it is just running a sequence of riverctl commands. I found it very ergonomic since i can test config in the cli, I can just use a bash script to run commands — and some extra daemons like mako, waybar, and wlsunset
> xmonad is really really good. Especially how it handles workspaces on multiple monitors

This is the reaon I use XMonad, and I hate how this one design choice that only one window manager has gotten right is what locks me into X11. If anyone ever learns of a non-X11 window manager that handles workspaces on multiple monitors the XMonad way, contact me!

I got good and bad news: my own WM did it Xmonad style, but I have not updated it in years. If there is enough request I might revive it (also X11 though, so not fitting the bill).

See https://github.com/Kintaro/wtftw It handles screens the exact same way Xmonad does, because it was modeled after Xmonad. The config is entirely done in Rust, so it allows for a lot of hackability. On reload, the config gets compiled to a dynamic library and the WM restarts itself, passing the current window IDs to itself to "reload".

But I was meaning to pick up a new project in 2026 for myself. So maybe a CL based Wayland WM with an Xmonad style?

Well, if you do get around to it, I might just be your first user!
Back when I had my own Xmonad config – during student years with too much time than I knew what to do with – the biggest benefit to Xmonad being a haskell program that I myself wrote was that it was a program that I myself wrote.

This meant that instead of e.g. spawning some utility on a media key input, the compositor could directly stay connected to the dbus and control mpdris clients directly.

The way I see xmonad in retrospective today is that it is/was a "make your own compositor" library much like wlroots, smithay, etc, but it came with enough of the batteries included in the package that spinning up a nice and productive environment took barely any code. Something you can't really do with wlroots or similar.

> Configuring your WM in Haskell seems fun, but I suspect "fun" is the primary motivator, not any kind of practical reason.

Not for me. I don't know Haskell, and I had to cargo-cult forms to do what I want (which bothers me, as someone towards the end of the developer spectrum that likes to understand well how systems work).

But XMonad with a few cargo-culted tweaks works noticeably better for me than I've been able to configure i3wm. I forced myself to use i3wm at one company, for two years, rather than bring over my Xmonad config, and every evening it was a relief to be back using Xmonad on my personal laptop.

I haven't used it in some years, but I found AwesomeWM to work well for me for the usecase of configurable predefined window layouts. Is there anything in particular about Xmonad that keeps you coming back?
> you're going to discover that the keybinding doesn't work when you go to use it, so how much time are you really saving?

It's not about discovering it doesn't work so much as discovering the specific reason it doesn't work.