sl0ppty: three ways back from a painted pane

    printf '\033]5577;1;shader;\033\\'                  # from the program
    sl0ppty cmd '{"cmd":"clear-shaders","id":0}'   # from outside it
    bind "z" "clear-shaders"                       # from the keyboard

`app_clear_pane_shaders` empties both of a pane's chains and says whether
there was anything there, which is what lets a key answer "shaders cleared"
or "no shaders on this pane" instead of maybe having done something.

In-band it is not a new verb: naming no rect means all of them. `shader;`
sits under `shader;chrome;` and `shader;content;` as the degenerate case of
"which rect", so a program puts a pane back in one exchange and cannot leave
it half done. `contrib/shader-repl`'s `:both` now uses that rather than two.

**None of the three is gated on `in_band_shaders`.** A chain outlives the
setting that allowed it -- paint a pane, then turn the setting off, and the
paint is still there, because a chain belongs to the pane and not to the file
(there is a test that reloads with it off and clears anyway). A way out that
the setting can take away is not a way out. The operator path matters for the
same reason: the program that made a pane unreadable is not always in a state
to put it back.

They clear what the *pane* set. The config's chains and the session's own
dimming are not this pane's doing and are derived every frame anyway.

The action is bound to nothing, like `scroll-up`: it is in the palette, which
is what the palette is for, and the docs say to bind it if you leave the
setting on. Which is where a second bug turned up -- the palette truncates a
label at 26 characters, so "undo this pane's own shaders" read as "undo this
pane's own shade" on screen. Renamed to fit, and `tests/test_palette.py` now
checks every label against the column, since nothing failed for that: it just
looked like a typo in front of someone.

1 files changed, 5 insertions, 1 deletions

diff --git a/docs/scripting.md b/docs/scripting.md
index 298ae17..0f398ff 100644
--- a/docs/scripting.md
+++ b/docs/scripting.md
@@ -29,6 +29,7 @@ Panes and tabs are addressed by **id**, so a background tab is scriptable.
 | `split` | `dir:"cols"\|"rows"`, `id` for which pane to split |
 | `focus` | `id` |
 | `close` `rerun` | `id`, or 0 for the focused pane |
+| `clear-shaders` | `id`, or 0 for the focused pane; answers `cleared:0\|1` — the way back from a pane that painted itself unreadable |
 | `new-tab` `select-tab` `close-tab` `move-tab` `set-name` | tabs, by `id` or `index` |
 | `set-purpose` | `target:"pane"\|"tab"`, `id`, `purpose` |
 | `dump-layout` `apply-layout` | see [layouts](layouts.md) |
@@ -61,7 +62,10 @@ 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).
+before it is a convenience. `shader;` with no rect named clears both of that
+pane's chains, which is never refused -- and `clear-shaders` above is the same
+thing from outside, for a program that will not do it itself.
+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