> I'm not going to spend days of my life digging into their source code to make the changes I want
This is an odd thing to bring up though because that's quite literally the only way to make any changes to suckless software, editing source code in C.
The entire philosophy behind is entirely performative in many ways. There's nothing simple or "unbloated" about having to recompile a piece of software every time you want to make what should really be a runtime user configuration, and it makes an entire compiler toolchain effectively a dependency for even the most trivial config change.
I tried their window manager out once and the only way to add some functionality through plugins is to apply source code patches, but there's no guarantee that the order doesn't mess things up, so you basically end up manually stitching pieces of code together for functionality that is virtually unrelated. It's actual madness from a complexity standpoint.
> This is an odd thing to bring up though because that's quite literally the only way to make any changes to suckless software, editing source code in C.
You're ignoring the part where the tools are often a fraction of the size and complexity of similar tools. I can go through a 5K SLOC program and understand it relatively quickly, even if I'm unfamiliar with the programming language or APIs. I can't do the same for programs 10 or 100x that size. The code is also well structured and documented IME, so changing it is not that difficult.
In practice, once you configure the program to your liking, you rarely have to recompile it again. Like I said, I'm using a 5 year old st binary that still works exactly how I want it to.
Maintaining a set of patches is usually not a major problem either. The patches are often small, and conflicts are rare, but easily fixable. Again, in my experience, which will likely be different from yours. Our requirements for how we want the software to work will naturally be different.
The madness you describe to me sounds like a feature. It intentionally makes it difficult to add a bunch of functionality to the software, which is also what keeps it simple.
I'm not a C programmer, so it would probably personally take me days, maybe weeks to fully grok 5K SLOC of C. Still, it is potentially possible if I made the effort, unlike with other programs, like you say.
It's a testament to the quality of the original C code that I was able to configure and use st and other suckless tools with my limited experience. An experienced C developer would probably find it a breeze.
I have a small config for Kitty that does not require any patching and recompilation and can survive Kitty updates for years to come. I don't understand why I need to study the source code of my terminal emulator.
I quite liked Kitty, and wanted to keep using it. But the slow startup was a deal breaker for me. Even with `--single-instance` it was at least 5x that of st for me, which is noticeable for an app I use very frequently. Besides, I'm not a fan of running a single instance of any app, since if (when) it crashes, all my work is gone.
Then I had a look around their issue tracker, and noticed others complained about this too[1]. And the dismissive and defensive response from the author just rubbed me the wrong way.
Strange, it actually endeared him to me. Thanks for the link. I guess some crusty part of me enjoys seeing someone who actually knows what they are talking about not putting up with whiny demanding randos on the internet. I might even give kitty a second chance on windows, to clarify I don't think you are wrong to feel the way you do, it just gave me a chuckle how differently different people parse things.
Sometimes, I have had to change software (although not from suckless, since I do not use any of their software) by modifying and recompiling it, to do what I wanted.
> There's nothing simple or "unbloated" about having to recompile a piece of software every time you want to make what should really be a runtime user configuration, and it makes an entire compiler toolchain effectively a dependency for even the most trivial config change.
It is true, but depending on the software, sometimes this is acceptable. (Some of the internet server software that I wrote (such as scorpiond) are configured in this way, in order to take advantage of compiler optimizations.)
For some other programs, some things will have to be configured at compile time (mostly things that probably don't need to be changed after making a package of this program in some package manager), although most things can be configured at run time and do not need to be onfigured at compile time.
> I tried their window manager out once and the only way to add some functionality through plugins is to apply source code patches, but there's no guarantee that the order doesn't mess things up, so you basically end up manually stitching pieces of code together for functionality that is virtually unrelated. It's actual madness from a complexity standpoint.
This is a valid criticism, and is why I don't do that for my own software. However, it is sometimes useful to make your own modifications to existing programs, but just applying sets of patches that do not necessarily match is the madness that you describe.
Not when you want to write your own patches, it isn't. I think the design of DWM could be improved to make patching easier, but it was a revelation to me when I discovered it: for the first time in my life, I was using open source software that was actually designed to be extended.
This is an odd thing to bring up though because that's quite literally the only way to make any changes to suckless software, editing source code in C.
The entire philosophy behind is entirely performative in many ways. There's nothing simple or "unbloated" about having to recompile a piece of software every time you want to make what should really be a runtime user configuration, and it makes an entire compiler toolchain effectively a dependency for even the most trivial config change.
I tried their window manager out once and the only way to add some functionality through plugins is to apply source code patches, but there's no guarantee that the order doesn't mess things up, so you basically end up manually stitching pieces of code together for functionality that is virtually unrelated. It's actual madness from a complexity standpoint.