Engineering blog
Longer write-ups on how TUIOS and its sibling tools were built, measured and fixed. Every number here came out of a run that can be repeated from the repository.
The cell was half measured and half guessed
Two rounds of obviously correct font maths in the screenshot renderer, both wrong. The number that settled it did not come from a font file. It came from holding the picture up against a running terminal.
The terminal was falling behind on drawing the fact that it was falling behind
A pane kept painting for 1.2 seconds after the program flooding it had exited. The backlog was not caused by the flood alone. The client's own renderer was taking the drain time it needed to catch up.
The fuzzer that found nothing, and the two questions that found everything
590,000 fuzz executions against the terminal emulator reported nothing, while a conformance round done by hand found eleven bugs. The fuzzer was checking that the screen was well formed. Nothing was checking that it was right.
A fifth of every frame went to changing nothing
The renderer's second-hottest call was a word wrapper running over text a terminal emulator had already laid out to exactly the right width. Deleting it was easy. Proving the deletion safe was the actual work.
My differential tests passed and the screen was pink
A second terminal emulator, a differential suite comparing it against the first from day one, and every filename in ls rendered on hot pink. The suite compared the right things at the wrong time, in the wrong representation.
The daemon said yes to an option that did not exist
Driving the control socket the way a machine would, instead of testing its handlers the way I had been, found a typed command that lost its spaces, a parameter that was silently discarded, and a settings surface where six paths out of 88 were real.
The bug I closed three times
A speckled sprite in the browser terminal. Three closures, each resting on a different wrong conclusion, a test suite blind by construction, and an instrument that was corrupting its own measurements.
I dragged one divider and five windows moved
One resize report turned out to be three separate defects, a wrong theory, and one behaviour that was correct all along. Benchmarks saw none of it. A log of who moved saw all of it in a single drag.
The benchmark said 27x faster. It felt worse.
Resizing a pane in TUIOS lagged behind the mouse. Go's profiling tools found the cause, killed two theories I was sure about, and then spent three rounds accurately measuring the wrong thing.
My fuzzer was optimising for my own bug
A flaky fuzz suite turned out to be a PTY I never configured, and a minimiser that hill-climbed straight toward the defect. It handed me the answer for two days while I ignored it.
My multiplexer lied about what it could do
Images worked in the terminal, worked in the multiplexer, worked in the browser client, and failed the moment you stacked all three. The middle layer was answering a capability question it had never asked anyone.
I ported a correct width table and it fixed nothing
Grapheme widths were wrong in the browser client, so I lifted the tables from an implementation that gets it right. Measured it. No change at all, for a reason that took me longer to see than it should have.
I shipped three fixes for a bug I had not found
A pane went blank when I focused a different one. I found and fixed three real bugs on the way to the actual cause, and shipped every one of them as the answer.
Three bugs in one month turned out to be one bug
A terminal is a request-response protocol that most people write as if it were one-way. I hit the same bug three times in a month, in three different codebases, pointing three different directions.