You’re probably thinking of dwm. Another great tiling window manager.

If i3 is descended from wmii, that's news to me.

wmii moved to Google Code[1] before becoming abandonware before Google Code shut down.

Nevertheless, I continue to use wmii as my daily driver (as it has been for just a few months shy of 10 years), but it's really starting to wear on me that bugs won't be fixed unless I fix them[2], which I no longer have the gumption to do.

[1] https://code.google.com/archive/p/wmii/

[2]: https://code.google.com/archive/p/wmii/issues/270 (when Google Code archived, a lot of users got weirdly anonymized? "Swift Bird" is me, apparently?)

> If i3 is descended from wmii, that's news to me.

I meant as heavily inspired by it, not as based on the same code. From https://i3wm.org/:

> Based upon the experiences we made when wanting to hack/fix wmii, we agreed upon the following goals for i3...

Also, from the manpage i3(1):

> i3 was created because wmii, our favorite window manager at the time, didn’t provide some features we wanted (multi-monitor done right, for example), had some bugs, didn’t progress since quite some time and wasn’t easy to hack at all (source code comments/documentation completely lacking). Still, we think the wmii developers and contributors did a great job. Thank you for inspiring us to create i3.

> wmii moved to Google Code[1] before becoming abandonware before Google Code shut down.

Both wmi's and wmii's code can also still be obtained at https://dl.suckless.org/. Those are packages, though. It's great that the repo for wmii is still available. Thanks for those links.

If you did switch away from wmii, what window manager would you switch to? I’m in the same situation where after using wmii for so long none of the other tiling window managers feel right.

Not LukeShu, but I skimmed the guide for wmii from the WaybackMachine and found its idea of events quite unique and interesting (though I'm not sure I can think of a good use for it). i3 seems like it might have something like it, but that particular feature doesn't seem to be well documented.

Anyway, I wanted to ask you both, what do you like most about wmii that you'd miss by switching?

"Configuration as code" is a concept that really speaks to me. It's the ethos of Emacs (which I also use), and wmii does it as well.

<tangent>In fact, for a long time (now I'm not so sure) I even thought wmii did it better than Emacs: Instead of being tied to one language and one process, wmii exports everything as a filesystem, and you configure it by writing a program that inspects and modifies that filesystem. Instead of being tied to operating on in-memory objects in Lisp, you're operating on in-filesystem objects in the language of your choice. (Today, I still think configuration by exporting a 9p filesystem is a powerful idea, but I've come to realize some of wmii's assumptions are a little opinionated to where I'm less sure about "better than Emacs"). I'd previously used StumpWM, which is configured in Common Lisp and is very similar to Emacs; I wasn't very comfortable in Lisp (and am still not terribly comfortable in it, though much more than I was), and also at the time StumpWM wans't packaged in the main Arch/Parabola repos and wmii was.</tangent>

It's my understanding that most wmii users use one of the standard/example "wmiirc" scripts, and fuss with a few variables and make minor tweaks to customize it to their liking. My wmiirc (while inspired by the stock one), is written entirely by me. My code reads events from a socket on the filesystem, and then manipulates other files in the filesystem in response. It's like, even without taking the time to fully understand wmii's codebase, I feel like I have a very robust understanding of exactly what it's doing, as if I did understand the full codebase; because every action it takes is because of a line of code I wrote. And related to that, I'm pretty sure no other human in the world has their window manager keybindings set like I do; how it's configured is very personal and "mine".

I don't want a static configuration file, I want a dynamic configuration program. As a stupid example of "configuration as code": For most of the last 10 years I had a file of hex color codes to configure the color theme for wmii. Usually what would happen is I'd switch my Emacs color theme, then some time later adjust the wmii theme to match. A month or two ago, I got sick of that, and adjusted it to dynamically use `emacsclient --eval` to just query Emacs about the colors of its current theme, so I never have to deal with it again.

I would miss wmii’s layout model the most, specifically how the screen is divided into columns and each column is either stacked or collapsed. Perhaps there are other tiling window managers that work this way but I haven’t found one.

I would also miss wmii’s tagging which is incredibly flexible. I often have one window on multiple named tags (which are roughly like workspaces).

In i3/sway, windows are organized in a tree structure where application windows are the leaves. Non-leaf nodes are called containers and can be tiled vertically, tiled horizontally, stacked, or tabbed. Windows and containers can be either floating or tiled on the workspace. It seems like i3's layout model is a superset of wmii's.

wmii's tagging does sound unique if I understand correctly that you can have 1 window in multiple workspaces and correspondingly in multiple positions and sizes. Something like that sounds like it would be problematic for handling multiple monitors, though. If one window is to be in 2 workspaces, what's supposed to happen when you want to show both workspaces at once in separate monitors? Can't show the same window in 2 places at once with different sizes.

A wmii tag workspace encompasses all the monitors; if I switch tags on one monitor, it switches tags on all monitors; you can't show multiple tags at once.

In principle, wmii handles multiple monitors great; it's had Xinerama support the entire time I've used it (checking mercurial, since late 2008; first being included in a stable release in late 2009). Though, I've been discovering that it has some bugs with layouts that aren't just the monitors tiled horizontally. (That doesn't stop me from using it that way, just that there's some bugs for me to grumble at.)

The "obvious" answer for me is EXWM; since I'm an Emacs user anyway. The things keeping me from EXWM (besides just finding time to make the switch) are that:

1) I'm concerned about Emacs being single-threaded; on the boxes that I use Wanderlust (an Emacs mail client) on on large folders (such as the git devel mailing list, which receives thousands of emails every month), Emacs can stall for 10s of seconds. Packing on even more of the system to that single-threaded event loop worries me (especially if I can't even switch to another program during that stall).

2) I'd like to try Wayland at some point, so it seems like if I'm going to go through the trouble of switching, it should be something that is future-compatible.

> 2) I'd like to try Wayland at some point, so it seems like if I'm going to go through the trouble of switching, it should be something that is future-compatible.

You both have probably heard of it, but in case you haven't, Sway[1] is like a port of i3 to Wayland. Since i3 is based on wmii, Sway might be your best bet.

Regarding programmability, I'm not sure exactly how similar Sway is to i3, but you can get quite far in scripting configuration using the included i3-msg[2] executable. i3 keeps a socket open where you can send it commands or query its state. So, you can use it to "program"/"extend" i3 from any language by calling i3-msg.[3] This doesn't go as far as what you can achieve with a live programming environment like the Lisp WMs you mentioned, but it's something.

The manpage says you can also subscribe to events to listen to them, but it doesn't seem to mention what events these are.

[1] https://swaywm.org/

[2] https://www.mankier.com/1/i3-msg

[3] As an example, a little configuration I've done is adding a command (called via keybinding) that moves back and forth the floating windows of the current workspace to a new workspace that's named based on the current workspace. In other words, it's a keybinding that shows or hides the floating windows of a given workspace without mixing the floating windows between the different workspaces. I use i3-msg to query the name of the current workspace, to check if there are floating windows in the workspace, and to send the command to send these windows to or from the alternate workspace corresponding to the current one.

it took me a while but I migrated to Awesomewm & found it quite enjoyable for a good number of years. the model was a bit different but i got used to it & i think overall it sped me up, although i wasn't quite as in control/exacting as i once was with layouts & order.

in the past year i finally started making myself use Wayland instead of X11, & the natural/mainstream go to there is Sway. Sway is a lot like wmii or i3, much more so than Awesome, alas minus the 9P interface wmii had that i really wish i'd spent much more time learning & enjoying & scripting; definitely one of the coolest things i've ever been around, & i just chronically under-used it. had a couple play around sessions but never brought any scripting in to use the 9P interface on a regular basis to enhance my environment/do stuff.