sl0ppty: sl0ppty --check

A config linter, on the CLI:

    $ sl0ppty --check                     # what a session would read
    $ sl0ppty --check themes/mine.kdl     # or a file you have not installed
      config.kdl:101: bad prefix: ctrl+nosuchkey
      themes/mine.kdl:7: unknown shader: bloom
    ~/.config/sl0ppty/config.kdl: 2 problems
    $ echo $?
    1

A mode rather than a script, because the only checker that cannot drift
from what a session does is the loader a session uses. The single
difference is how many problems each reports: a session has one status
line and shows the first, and a linter that stopped at the first mistake
would make you run it once per mistake.

Exit 1 when it has anything to say, so it drops into an editor's compile
step or a pre-commit hook with no glue. A clean run prints what it read --
the files, including everything `include`d, the prefix it ended up with,
how many bindings -- because a config that was never opened and a config
with nothing wrong otherwise look identical, and "it printed nothing" is
not evidence.

An optional path so it can lint a theme before you install it, and
$SL0PPTY_CONFIG is honoured when there is none, so it checks the same
file the session will.

tests/test_check.py covers the contract: exit status both ways, every
problem reported rather than the first, file and line on each, an
included file naming itself, a file that will not parse saying nothing
applied, a missing file being a problem rather than a crash, and the one
that would have caught the bug in the commit before this -- a config
written by `--dump-config` lints clean.

1 files changed, 27 insertions, 0 deletions

diff --git a/docs/config.md b/docs/config.md
index 4572404..e18f91e 100644
--- a/docs/config.md
+++ b/docs/config.md
@@ -30,6 +30,33 @@ already loaded needs a new session.
   setting is for, what it cost to get right, and which ones are opinions. When
   the two disagree, the dump is right and that file is stale (a test says so).
 
+## Checking one
+
+```bash
+$ sl0ppty --check                     # the config a session would read
+$ sl0ppty --check themes/mine.kdl     # or one you have not installed yet
+```
+
+Every problem it found, one per line, with the file and line it happened at:
+
+```
+  config.kdl:101: bad prefix: C-a
+  config.kdl:116: bad key: ←
+  themes/mine.kdl:7: unknown shader: bloom
+~/.config/sl0ppty/config.kdl: 3 problems
+```
+
+It exits 1 when it has anything to say, so it drops into an editor's compile
+step or a pre-commit hook with no glue. A clean run prints what it read — the
+files, the prefix it ended up with, how many bindings — because otherwise a
+config that was never opened and a config with nothing wrong look identical.
+
+It is the loader, not a second implementation of it: the only checker that
+cannot drift from what a session does is the one a session uses. The single
+difference is how many problems each reports — a session has one status line and
+shows the first, and a linter that stopped at the first mistake would make you
+run it once per mistake.
+
 ## include
 
 A config can be made of files: