I have been experimenting with xdotool windowmap/windowunmap and override_redirect (and maybe LD_PRELOAD?) to try get something like EXWM to work without creating another X server, by capturing windows. I'm doing this in vim though.

By the way, neovim has an apparently working EXWM-like plugin, NXWM/nwm: https://github.com/altermo/nwm

ʕ•ᴥ•ʔ Bear vs. ʕ·ᴥ·ʔ Build EAR

The compilation database tool (https://github.com/rizsotto/Bear), is extremely helpful. It got CCLS/clangd working for me over multiple in-house build systems at a vfx studio.

It also is super helpful for debugging. I have used it a lot alongside a script which converts a compile_commands.json to a sequence of commands, so I can edit them individually without fiddling with the build system, and then once fixed (such as adding a flag to one TU) try to find the way to do that in the build system.

Then it is a pragmatic decision, using tmux you get to use the ecosystem of things like tmuxinator which explicitly target tmux to get a known number of terminal features like splits. What I learn from the OP, is that there are technical reasons that tmux is not a "good design" - like Kovid's comments on how it constrains innovation in terminal designs - which might lead someone to consider, what actually does tmux do and could my workflow be implemented otherwise?

It might be a bunch of unixy hacks and tricks (as another commenter here said) but it can work. I'd imagine recreating something like tmuxinator would be hard though, but it could also be interesting, like having arbitrary GUI programs configured to appear in "splits" using tiling integrated seamlessly within the terminals. But yeah, if the workflow is already set up and serviceable and supported with a community, using tmux, then I'd just keep using it.

He makes an intriguing point.

There are a few algorithms like some cloth sims based on particle positions and springs, which can be coded easily, but that was misleading to me when trying to improve, I had to dig a lot more into physics and numerical analysis then mapping the problem to code, which can end up clunky and with a lot of magic numbers.

Also I am really enjoying your article, still reading it with wikipedia open on the side haha.

So I guess I don't need to think too much of the functionness of splitting up a code-block, I suppose this example contradiction would also apply and more cleanly if just thinking of the compiler considering blocks of code individually e.g. in a greedy algorithm.

(Actually reading the intro again I think I overcomplicated this and he actually does mean just splitting into code blocks. My mistake)