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.

0 files changed, 0 insertions, 0 deletions