sl0ppty: `:load` a preset, without a second KDL reader

    chrome> :load sine-comet
    sine-comet.kdl: 1 chrome, 0 content
    chrome> :paste
    // sine-comet.kdl
    include "/home/user/dev/sl0ppty/contrib/chrome/sine-comet.kdl"

A path, or the bare name of anything in `chrome/` or `shaders/` beside the
script, from any directory. Entries land wherever their own `where=` says, so one
file can fill both chains and a preset goes where its author put it. Tab completes
filenames after `:load` and vocabulary everywhere else.

**The prompt does not parse the file.** I started writing the scanner -- find the
`shaders {` block, count braces, strip `//` outside quoted strings so that
`color="#ff0033"` and `t / 8` survive -- and stopped, because that is a second
reader of a format that already has one, and the two would disagree exactly where
comments meet strings. Instead the session gets the path and reads it with the
parser it already has: `config_parse_chain_file`, built on the same
`parse_shader_entry` a config file goes through. Anything that is not a top-level
`shaders { }` block is ignored, so a whole `config.kdl` can be handed over and
only its shaders apply.

The alternative was regenerating all 45 presets into something easier to read from
Python. That would have cost them what makes them useful: each one is a config
fragment today -- pasteable, `include`-able, checkable with `sl0ppty --check`, and
loaded as a config by `tests/test_chrome_presets.py`. A format only the prompt can
read would be a fourth thing to keep in step.

`:paste` after a load answers with an `include` line rather than the file's thirty:
the file is on disk, it is already the block, and reprinting it scrolled the pane
you were looking at -- which is how I noticed.

Both chains are built beside the live ones and swapped in together, so a file that
goes wrong half way leaves the pane as it was rather than wearing the half that
parsed. Each compiled expression is matched to the chain whose shader points at it
before either is installed; freeing a program the other chain still uses is the one
bug here that would not appear until the next repaint.

Verified: nine checks in `tests/test_shader_repl.py` -- a preset by bare name, a
file with both rects going to both chains, the three ways to be wrong (no such
file, no `shaders { }` block, no argument), what `:paste` says afterwards, and tab
completion. Then all 45 shipped presets loaded by name in one session: none
refused.

2 files changed, 12 insertions, 1 deletions

diff --git a/docs/scripting.md b/docs/scripting.md
index 0f398ff..d07d78f 100644
--- a/docs/scripting.md
+++ b/docs/scripting.md
@@ -64,7 +64,10 @@ 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. `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.
+thing from outside, for a program that will not do it itself. `shader-load;<path>`
+hands over a `shaders { }` file instead of a chain and answers with how much of it
+ran (`ok;1 chrome, 0 content`), so a script can apply a preset without knowing how
+to read one.
 See [shaders](shaders.md#prototyping-in-a-pane).
 
 Anything the session sends *back* to a program ends its verb in `-reply` --
diff --git a/docs/shaders.md b/docs/shaders.md
index 5197cb9..9b81398 100644
--- a/docs/shaders.md
+++ b/docs/shaders.md
@@ -123,6 +123,7 @@ not always in a state to put it back:
 | | |
 |---|---|
 | `printf '\033]5577;1;shader;\033\\'` | from the program, one exchange, both rects |
+| `printf '\033]5577;1;shader-load;/path/to/preset.kdl\033\\'` | a `shaders { }` file, read by the session and routed by `where=` |
 | `sl0ppty cmd '{"cmd":"clear-shaders","id":3}'` | from outside; `id` 0 or absent means the focused pane |
 | the `clear-shaders` action | on a key you bind, or from the palette |
 
@@ -136,6 +137,13 @@ pane change, and `:paste` prints what you have as a `shaders { }` block for your
 config. What you prototype and what you paste are parsed by the same code, which
 is the point of using the config's syntax for a thing typed at a terminal.
 
+`:load` takes any of the ready-made files -- `:load sine-comet` from anywhere,
+because the preset folders sit beside the script -- and its entries land wherever
+their own `where=` says, so one file can fill both chains. The *session* reads the
+file, with the parser that already knows the format: nothing in the prompt parses
+KDL, because a second reader of a config file is a second opinion about what it
+says. After a load, `:paste` prints the one `include` line that keeps it.
+
 It is a readline prompt, so editing, up/down and ctrl-r work as they do in a
 shell, and history is kept between runs in
 `$XDG_DATA_HOME/sl0ppty/shader-repl.history` -- the chains only, since `:quit` is