The whole is less than the sum of its parts

2026-11-04

1. Preamble

There I was, minding my own business, happily using what I believed to be the pinnacle of keyboard-centric computing:

a terminal-based text editor
a terminal multiplexer
a terminal emulator
a window manager

This is the “Unix way.” This is also the “suckless” way. The Right Way. Why? Because there is no bloat. Each thing does what it needs, and nothing more.

\underset{\begin{matrix} Same capability as \\ a unified system \end{matrix}}{\underset{⏟}{| ⋃_{𝑖 = 1}^{𝑛} 𝑇_{𝑖} | = | Ω |}} and \underset{\begin{matrix} Zero redundancy \\ there is no bloat \end{matrix}}{\underset{⏟}{\sum_{𝑖 = 1}^{𝑛} | 𝑇_{𝑖} | - | ⋃_{𝑖 = 1}^{𝑛} 𝑇_{𝑖} | = 0}}

Yet, somehow, when used together, the whole is less than the sum of its parts.

2. Death by a thousand cuts

2.1. Big cut

Lately, I’ve been involved with a fair bit of technical writing. This means Confluence and Mermaid diagrams.

At first, I resorted to using Mermaid’s online editor to build out my diagrams, download them, and view them as normal image files. This works well enough for one-off diagrams, but eventually keeping track of the code “next” to its diagram becomes a pain to manage.

One option is to use GitHub-flavored Markdown’s built-in support for Mermaid. You just write Mermaid in code blocks in Markdown and render it. Except the only real tool I found that does this is mpls. This works, but it starts a web server to serve the preview as HTML, requiring me to open my browser to view it. Ugh! There goes the keyboard-centric empire I worked so hard to build.

Now I know I could technically configure my browser to be keyboard-driven too - and I already do this using Vimium - but this just isn’t the same. Not to mention, it still requires me to maneuver the browser tab with the preview to separate it from all my other tabs in my browser and split-screen it next to my editor. All this just to view a damn Markdown file?? Surely, there has to be a better way?

I know what you’re thinking. I’m doing it wrong. Any competent window manager should make this easy enough that it’s not a big deal. You might be right. And if this were me a decade ago, I would’ve taken this as a personal obligation to defend the Unix way, and concoct a hacky-ass script to automate the fluff to make this mostly work. But I don’t have that desire anymore. Besides, this is my work computer, and every tiling window manager I’ve tried on macOS has its own quirks that have put me off of them for a good while.

I just want to view the damn thing right there in my editor.

I imagine this is trivial for VS Code people. Have they been right this whole time? Has it all been a sham?

2.2. Small cut

When I sit down to write for my blog, I perform this ritual:

launch a terminal window
start the terminal multiplexer
open a floating pane and start the process that watches for updates and serves my blog locally
launch the text editor in another pane to start writing
launch the browser to the local web server serving my blog
switch back and forth between the two as I write

Now to be fair, it is possible to automate some of this away. For example, one could combine the first two to happen automatically by default (not without consequences). One could have some kind of layout macro for their multiplexer to combine the third and fourth steps (and maybe even the fifth).

But I hardly blog. I do not want to write automation for something I do so rarely. What’s more is that I frequently forget the incantations required to launch a floating pane in the first place. I know what you are thinking. This is on me. I should just use a normal terminal with nohup for the background process and do away with all the multiplexer fluff. Except when I do write, I often use images, and I find having a dedicated pane where I can do file operations like previewing, renaming, etc., while being able to switch back and forth between it and my editor quickly is very useful. OK, but can’t the window manager just do it all? I’m hardly ever only blogging. I often have other ongoing sessions for other things. So I would have to give up the session management from the terminal multiplexer in favor of some archaic workspace-based management from the window manager.

I’d rather just have the same workflow for all the work.

2.3. Small cut

I often want to embed images for my blog posts. It’s quite helpful to view the image I am referencing in my file to make sure that it is indeed what I intend to display there.

Well, as mentioned above I can do this using a dedicated pane on my multiplexer next to where I edit. Here is how I got it to work. You see, my file manager - yazi - supports image previews, but it relies on graphical support from the terminal emulator. OK, just build st with the Kitty Graphics protocol. That works when launched directly within the terminal, but not when launched from within a multiplexer session. D’oh!

Eventually I found the perfect combination of dependencies to make this work, but this left me with a bad taste in my mouth.

3. Conclusion

In a vacuum, each tool is individually great. But there is no integration between them. Attempting to integrate them requires you to take a union of all the tools that offer incomplete (sometimes conflicting) variants of the same feature that overlap with each other, and then bolt on the glue that integrates them. You can easily end up (like me) with a system that is less capable and more bloated, because they were not designed to integrate.

\underset{\begin{matrix} Less capable than \\ a unified system \end{matrix}}{\underset{⏟}{| ⋃_{𝑖 = 1}^{𝑛} 𝑇_{𝑖} | < | Ω |}} yet \underset{\begin{matrix} More bloated than \\ a unified system \end{matrix}}{\underset{⏟}{\sum_{𝑖 = 1}^{𝑛} | 𝑇_{𝑖} | + (\binom{𝑛}{2}) | 𝐺 | ≫ | Ω |}}