sl0ppty: a pane can set its own shaders

    printf '\033]5577;1;shader;chrome;tint color="#ff5fd7" amount="abs(t / 8 % 510 - 255)"\033\\'

The field after `shader` is which rect -- `content` or `chrome` -- and the
rest of the payload is a chain in exactly the syntax a `shaders { }` block
uses, taken verbatim so that `;` can go on separating entries. Empty text
clears that chain. The session answers on the program's stdin, `shader-reply;ok`
or `shader-reply;error;bad amount for tint: ...`, because a prototyping loop
that gets no answer cannot tell a typo from a build without the feature.

`contrib/shader-repl` is the prompt this exists for: type a chain, watch the
pane, and `:paste` prints what you have as a config block. Both ends are the
same parser, so what you arrive at is what you can keep -- verified by
pasting `:paste`'s output into a file, linting it, and checking the frame
comes out the same colour.

**D13 said this was impossible on purpose, and the reasoning stands**: a
program that can restyle the session it happens to be running in is a hazard,
and `cat hostile.txt` should not dim your panes. But *impossible* was the
wrong shape for it -- editing a file, saving, looking and guessing again is
slow enough that shaders go unwritten. So it takes `in_band_shaders true`,
one line of consent, and it is scoped to the pane that asked: its own two
chains, never its neighbour's, never what the config said about anyone else.
There is a test for the neighbour.

Each chain owns the programs its expressions compiled to, and is swapped in
whole, so a chain that turns out not to read leaves the pane looking like it
did rather than half-restyled. Measured: 1,800 replacements of an animated
chain, resident size flat after the first pass.

Also here, because it is the same paint order: the chrome chain now sits
between the config's and policy's, exactly where the content chain does.
Dead code out -- `app_shade_add`/`app_shade_clear`/`app_shade_count` had no
callers and their comment claimed the opposite of what this commit does.

1 files changed, 11 insertions, 0 deletions

diff --git a/docs/scripting.md b/docs/scripting.md
index 0c27565..298ae17 100644
--- a/docs/scripting.md
+++ b/docs/scripting.md
@@ -58,6 +58,17 @@ printing a prompt and hoping.
 `purpose` is the other verb: `printf '\033]5577;1;purpose;logs\033\\'`. A purpose
 declared by a layout or the control API wins and cannot be overwritten this way.
 
+`shader` is the third, and the only one the session can refuse: it sets the
+shader chain for the pane that asked, in the config's own syntax, and needs
+`in_band_shaders true` because a program restyling your session is a hazard
+before it is a convenience. See [shaders](shaders.md#prototyping-in-a-pane).
+
+Anything the session sends *back* to a program ends its verb in `-reply` --
+`hello-reply`, `shader-reply` -- and no request verb may. A pane that echoes what
+it is sent (`cat`, a shell with echo on, a REPL waiting for a line) would
+otherwise be answered into a loop, which is exactly what `hello` used to do:
+4 MB of hellos in a second and a half.
+
 ## Headless
 
 `sl0ppty --script` is the whole program without a terminal: commands on stdin,