"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.
<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.