an opinionated terminal multiplexer in C with programmable pane chrome https://git.sl0p.foo/slosh.git/atom/tests/test_prefix.py?h=docs-new 2026-08-17T12:36:59Z 2026-08-17T12:36:59Z user user@clank 2026-08-17T12:36:59Z urn:sha1:c0022776d0912042819e4ea330cf7491a8196b45 The bumpy one, again. Every `.py` outside `vendor/` plus the three `contrib/` scripts that are Python with no extension: 60 files, 6,714 lines rewritten, no behaviour changed. Nothing here is worth reading -- the next commit adds it to `.git-blame-ignore-revs` so `git blame` walks past it. It is a bigger reformat than the C was, 60% of the lines against 17%, and for a reason worth writing down rather than tuning away: ruff and black break a call that does not fit onto one argument per line, where this code aligned the continuation under the opening paren. The test suite is thousands of `check("some prose", cond, detail)` calls, so nearly every one of them changed shape and the suite grew 3,308 lines. Line length was the one lever that moved it -- 120 columns would have been a 40% reformat and no growth at all -- and it was left at 88, because picking an unusual width to dodge a one-time diff is paying forever to avoid paying once. Import sorting came with it. Two files had `import os, pty, uuid, select, struct, sys, termios, time, fcntl, signal` on one line and now have ten. Verified after, not before, because a formatter that alters behaviour would be worse than none: - `make retest`, 1801 checks green -- and this reformats the suite that does the checking, including `harness.py`, which every one of those files imports. - `make test-live`, the tty tests the fast suite skips. They matter here more than usual: `live_input.py` and `live_m0.py` are two of the files whose comma-imports were split, and nothing in the fast suite would have noticed if that broke them. - All 60 files still compile, `make fmt` twice in a row changes nothing the second time, and `ruff check --select I` has nothing left to say. 2026-08-15T09:39:12Z user user@clank 2026-08-15T09:39:12Z urn:sha1:56bbd25f246f95d15dca992fa79328b37d515afe The leader has been configurable since M6 -- `keys { prefix "ctrl+b" }` -- and one place had not been told. The badge in the status bar, the indicator whose entire job is to say "you are in prefix mode", was the literal string "C-a" whatever you had configured. That is worse than not having the setting. A prefix you can change and a UI that keeps naming the old one teaches you to distrust the thing telling you which mode you are in, and it is precisely the person who rebound it -- the one who wanted C-a back for start-of-line -- who gets lied to. It renders the binding now, through the same function the cheatsheet uses, so the two cannot disagree. Measured rather than assumed to be three columns wide, because `C-space` is seven and `M-\`` is three of a different width. tests/test_prefix.py holds the whole story in one place: four prefixes, each shown correctly in the badge; the rebound key running commands; the *old* key going through to the program untouched (checked with `cat -v`, so a control byte arriving is visible as ^A rather than an invisible character that would prove nothing); the double-press still sending the key itself; and the cheatsheet agreeing with the badge. Also said it out loud in the README and the config, since the way this came up was somebody reasonably assuming it was not possible.