diff options
| author | user <user@clank> | 2026-08-16 15:05:02 +0200 |
|---|---|---|
| committer | user <user@clank> | 2026-08-16 15:05:02 +0200 |
| commit | ab8165a9717b4dd2b6dc750f504d4f67f6d9fdc6 (patch) | |
| tree | aca329fd1453a0739d714bcd190cd155780dd0ee /src/cmd.c | |
| parent | sl0ppty: a prompt with a memory (diff) | |
| download | slosh-ab8165a9717b4dd2b6dc750f504d4f67f6d9fdc6.tar.gz slosh-ab8165a9717b4dd2b6dc750f504d4f67f6d9fdc6.tar.xz slosh-ab8165a9717b4dd2b6dc750f504d4f67f6d9fdc6.zip | |
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.
Diffstat (limited to 'src/cmd.c')
| -rw-r--r-- | src/cmd.c | 8 |
1 files changed, 8 insertions, 0 deletions
@@ -168,6 +168,14 @@ static char *cmd_json(app_t *a, screen_t *s, input_parser_t *in, return jerr("no such pane"); return jok_int(NULL, 0); } + /* The way in from outside the pane, for when the program that painted it will + * not or cannot put it back. `ok` either way, with `cleared` saying whether + * there was anything there: a script asking for a clean pane got one, and that + * is not an error. */ + if (strcmp(cmd, "clear-shaders") == 0) { + bool had = app_clear_pane_shaders(a, (uint32_t)jv_geti(req, "id", 0)); + return jok_int("cleared", had ? 1 : 0); + } if (strcmp(cmd, "new-tab") == 0) { uint32_t id = app_new_tab(a, jv_gets(req, "name", "")); if (!id) return jerr("cannot create tab"); |
