slosh.git/tests/shader_test.c, branch master

sl0ppty: clang-format the tree

2026-08-17T12:22:38Z

The bumpy one. `make fmt` over every `.c` and `.h` outside `vendor/`: 32 files, 1,843 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. Two thirds of it is alignment the formatter now owns: trailing comments in a struct, continuation lines under a signature. The rest is the hand-packed tables opening up to one entry per line -- `ACTIONS`, `NAMED_KEYS`, `ACTION_HELP`. That is a real loss of density and a real gain in diffs: adding an action was a reflow of the block and is now one line. Anything worth keeping packed can be fenced with `// clang-format off`; nothing was, on the grounds that a table is the thing a formatter is for. **One change is not formatting.** `src/config.h` had three trailing comments glued onto one field: uint16_t hover_delay_ms; /* how long the pointer must rest to arm a guide */ /* how long an announcement stays up */ /* rows per wheel notch */ -- `toast_ms`'s and `scroll_lines`' comments, landed on their neighbour by an earlier edit, documenting the wrong things ever since. It is in this commit because it is what caught it: clang-format could not settle on that line, wrapping it one way and then re-indenting the wrap on a second pass, so `make fmt` was not idempotent. The comments are back where they belong and it is. Verified after the reformat, not before: `make clean && make all` is warning-free, `make retest` is 1801 checks green, and `make fmt` twice in a row changes nothing the second time. A formatter that alters behaviour would be worse than none, so the gate was the whole suite rather than a reading of the diff.

sl0ppty: zero strength is not a pass

2026-08-16T13:37:16Z

`shader_abi.h` has said `0 is identity` from the start, and the pass did not honour it: it materialised a cell's default colours -- resolving "whatever the terminal draws" into our `default_fg`/`default_bg` -- and only then called a shader that was contractually going to change nothing. So a chain that is currently *off* still repainted. `focused * 200` on an unfocused pane, `(since < 500) * 255` half a second later, `(x < 10) * 200` from column ten on: every one of those wrote our idea of the default over the terminal's own. Visible whenever the two differ, which for a real terminal theme is always, and invisible in the test suite because the tests compared against the materialised value. Found by measuring, not by reading: I was checking that each example I was about to hand over actually changed the pane, and one that should have changed nothing changed eight style runs. The fix is an ordering: work out the strength, and if it is zero leave the cell before touching it. A constant-zero shader now skips its whole rect before the loops. Cheaper too -- a pass that is off costs no materialisation and no call -- though that is a side effect and not the reason. Three test changes, all of them the same correction. `tests/shader_test.c`'s traversal probe was built `{.kind, .fn}` with `amount` defaulting to 0, so it was asking to be called for every cell at zero strength; it now asks for 255, which is what those checks are about. A new block pins the rule: a zero-strength pass visits nothing and leaves an unset cell unset. And four checks in `tests/test_shader_expr.py` asserted `== "#ffffff"` for cells outside an effect's band -- the materialised default. They now assert the cell has no colour of its own at all, which is the stronger claim and the one that would have caught this.

sl0ppty: shaders on the chrome, and two keys for the arrangement

2026-08-15T21:06:32Z

Five things, in one commit because they land in the same few files -- the action table, the shader pass, config.kdl -- and splitting them by hunk would buy a tidier log at the price of commits that do not build. Each is verified end to end; the suite is 46 files green. Chrome shaders. `where="chrome"` on any entry in `shaders` or in a `states` block runs that pass over a pane's frame -- border, padding, title, buttons -- instead of its contents. Nothing else changes: same registry, same `amount`, same expressions, same chain order, one new word, because a frame is another rect and so it is another pass. It runs over the frame's whole rect with the contents punched out as a hole, rather than four passes over four sides: an effect has to be able to travel round a border, and four passes would each count x/y from zero and restart at every corner. The hole keeps the two honest -- a skipped cell is never visited, so a full-strength chrome tint cannot reach your text. It is also the only kind of pass that can colour a pane a small window has collapsed to a single row (D6), which is the state where a colour is worth the most. `channel="fg"|"bg"|"both"` came out of looking at the first border flash: `tint` mixes both of a cell's colours, and a frame's background is the terminal's own default, so the pass materialised it to our guess at that default and mixed towards the colour -- a dark rectangle behind the glyphs, left there until the pane changed state. The mask is enforced by the pass, not the shader: the other colour is snapshotted before materialising and put back after, so an unset colour goes back to unset, it works for a built-in and a plugin alike, and no shader grows an fg-only twin of itself. A `bell` pane state and a `since` variable, because "flash the border when a pane rings" needed both and neither existed. `since` is milliseconds since the pane entered its current state, stamped in the one function that decides the state -- a transition is the one thing a frame cannot tell you, so it is remembered where it cannot disagree with the state it dates. `bell` ranks above the ambient states and below `dead`: a pane that rang while you were elsewhere is news, and a pane that rang and then exited is a pane that exited. It ends when you look at the pane, because that is what answering a bell is. Animation needed a clock and did not have one: a shader reading `t` only advanced when something else caused a frame, so a pulse froze the moment you stopped typing. `app_next_deadline_ms` now reports `anim_ms` while a chain that reads the clock ran over the last frame -- derived from what was applied, so a pulse hung off `dead` costs a clock while a pane is dead and nothing for the rest of the session. A `deadline` verb makes that observable; the server's poll loop already lived on the number. contrib/chrome has seven presets and the perimeter trick they are built on: on a frame the coordinate you want is distance along the ring, which the language can work out, and `min(d, P - d)` is what makes an effect cross the corner it started from. Hand-written, unlike contrib/shaders, because the toy previews contents and a frame has no preview to give -- so tests/test_chrome_presets.py checks each one the only way left: load it into a real session, assert the frame moves and the contents do not. `equalize` (C-a =) puts every share back to even: each split's children weighted by how many visible panes are behind them, so one pane beside a stack of three is a quarter of the width and "even" means the same thing at every depth. Exactly equal cell counts are not something a tree can always express, so the action promises the even division it can. `rotate-layout` (C-a Space) turns the whole tab a quarter turn clockwise. Every split changes axis and a row split's children reverse, because the pane on top of a stack is the pane on the right once you turn it; get that asymmetry wrong and you have a mirror image, which looks almost right until four turns fail to come back. They do come back, exactly, which is why the inverse is three more turns rather than a second mirrored routine with its own chance of being wrong -- and why a key as easy as space is the right one rather than a hazard. A turn is refused when it would not fit: a share of the height is not always a share the width can afford, and a node that cannot give its children their floor takes the whole tab down to a list. So the turn is tried, the layout is asked what it made of it, and one that flattened the tab is put back with a word. Same rule `split_fits` applies to splitting. Keys: the palette moves from `shift+p` to `p`, and cycling tabs from `n`/`p` to tab/shift+tab. `p` is pressed far more often than "the tab before this one" and was the only shifted letter in the defaults; tab is what every other tabbed thing cycles with, and `\e[Z` decodes as shift+tab on a plain terminal, so this costs nothing on a client without the kitty protocol. `n` is free again. The actions are untouched: two lines of config put the old binds back. The shader ABI goes to 3: `shade_ctx_t` gained `state_ms` and struct shader gained `channels`, both the pass's business rather than a shader's. Plugins need a rebuild, which is what the version is for.

sl0ppty: positional shaders, and a config block to ask for them

2026-08-14T12:13:33Z

Six passes that are pure functions of where a cell is: vignette, gradient, zebra, ruler, margin, spotlight. The position was already in the context and nothing had used it; these are what it was for. The one worth having on its own merits is `ruler`. A column guide that costs no columns, needs no support from the program in the pane, and works in anything — an editor that has never heard of one, a pager, a shell. It marks the background only: a guide that recoloured the text would be making the code it marks harder to read, which is the opposite of the job. `margin` is the same idea from the other side, everything past a column receding so an over-long line visibly runs out of the pane you meant to use. `spotlight` is the first thing to need something new in the context. The cursor belongs to whichever pane is focused, so it is handed only to that pane — otherwise every other pane's light would chase a cursor somewhere else. It leaves everything inside its radius completely alone, because dimming the text you are actually working on to make it easier to find would be silly, and ramps rather than stepping at the edge. `vignette` and `spotlight` both measure distance with a row counting double, because a cell is about twice as tall as it is wide and an effect that claims to be round has to say so in cells. The layout's own centre-distance already does this. The test for it is that on a 41x21 pane — square on screen, not in cells — the top edge and the left edge come out equally dark. Scanlines are not a seventh shader. A CRT scanline is `zebra` with a band of one row, and shipping the same arithmetic under two names would be pretending they are different things. These are not policy, so they needed a way to be asked for, and a KDL block whose children are the passes gets it without inventing a syntax: order in the block is order in the chain, because a chain is a sequence, and listing a shader twice is how you get two rulers. Unknown names are refused with a warning rather than guessed at. Empty by default — these are yours to want, not opinions we hold.

sl0ppty: terminal shaders — a colour pass over pane contents

2026-08-14T11:42:00Z

A shader is a pure function from (cell, position, parameters) to that cell's colours, applied to a pane's contents. Tinting, dimming and greying are the first three; the point is the mechanism, because it is going to carry a lot of UX later — drag a pane and grey the others, dim what is not focused, mark a pane that wants attention — and all of those want to be a colour pass rather than another special case in the drawing code. Where it runs is the whole design. draw_cb already paints the frame, then the contents, then the split guide, so the pass goes between the last two and "contents, not chrome" stops being a rule anyone has to remember: the frame was painted before and lies outside the content rect, and an affordance painted after stays legible on top of a pane that has been dimmed underneath it. node_t already carries the content rect, so the pass has its bounds. Cells only, and colours and attributes only. Rewriting a cell's text would desync selection and copy, which read the terminal rather than the screen, and could break the wide-cell invariant; the tail half of a wide cell is skipped for the same reason, since shading it computes a colour nothing displays. Each cell is shaded independently — no neighbours — so anything positional works and convolutions do not. That is deliberate: blur would need a second buffer, and everything actually wanted here is a function of position and colour. The context carries the content size and rect-relative coordinates so gradients and vignettes are expressible, plus a timestamp for whatever ends up animated. The one real problem is that "terminal default" has no RGB. We never learn what the client's default foreground is, and most terminal text is default-coloured, so a shader that skipped those cells would leave nearly everything at full brightness and read as broken. The pass materialises them to a configured default_fg/default_bg (white on black) before running, which means a shaded pane stops tracking the terminal's own theme for those cells — so the config exists to make that right, and asking the terminal directly with OSC 10/11 is the eventual fix. A pane with no shaders skips the pass entirely and still defers to the terminal exactly as before. Attachment is internal policy: app_shade_add/clear, callable from inside the app and from nowhere else. Not over the control API and not in-band, so a program in a pane cannot restyle itself. Nothing attaches one yet. Kitty graphics are re-emitted as images rather than cells, so a shader cannot touch them: a greyed pane keeps a full-colour image in it. Known and accepted. Tested as a C unit test, since the pass is pure: the built-ins and their strength scale, luma weighting, chaining order mattering, defaults being materialised, wide-cell tails and text surviving, degenerate input, what the context tells a shader, and — the one that protects the chrome — that the pass touches nothing outside its rect.