Is this a reproducible bug?
Current behavior
herdr config check reports config: ok and exits 0 when [theme] name is set to a value that is not a built-in theme, for example a typo like catppucin. The UI then renders the default theme.
The same command does report an unknown config key: unknown config key ui.accentt; ignoring key. So an invalid key name is surfaced while an invalid theme name is not. dark_name and light_name behave the same way as name.
Expected behavior
config check reports the unknown theme name, the way it already reports unknown keys and unsupported sound file formats, ideally naming the valid values and stating that the default is used. Falling back to the default theme is fine; the silence is the problem.
Reproduction
mkdir -p /tmp/herdr-theme/.config/herdr
printf 'onboarding = false\n[theme]\nname = "catppucin"\n' > /tmp/herdr-theme/.config/herdr/config.toml
HOME=/tmp/herdr-theme herdr config check
# -> config: ok (exit 0)
printf 'onboarding = false\n[ui]\naccentt = "#ff00ff"\n' > /tmp/herdr-theme/.config/herdr/config.toml
HOME=/tmp/herdr-theme herdr config check
# -> unknown config key ui.accentt; ignoring key
Impact
I theme two machines differently so I can tell them apart at a glance. When a theme name is wrong there is no signal anywhere in the CLI, so a typo is indistinguishable from "this theme just looks like that" — I spent a while adjusting individual colors before realising the base theme had never been applied. config check passing gave me false confidence that the file was correct.
Environment
- herdr version: 0.7.5 (also reproduced on a build of current master)
- Update channel: stable
- Operating system: CachyOS (Arch-based), Linux
- Terminal: kitty
- Shell: zsh
Is this a reproducible bug?
Current behavior
herdr config checkreportsconfig: okand exits 0 when[theme] nameis set to a value that is not a built-in theme, for example a typo likecatppucin. The UI then renders the default theme.The same command does report an unknown config key:
unknown config key ui.accentt; ignoring key. So an invalid key name is surfaced while an invalid theme name is not.dark_nameandlight_namebehave the same way asname.Expected behavior
config checkreports the unknown theme name, the way it already reports unknown keys and unsupported sound file formats, ideally naming the valid values and stating that the default is used. Falling back to the default theme is fine; the silence is the problem.Reproduction
Impact
I theme two machines differently so I can tell them apart at a glance. When a theme name is wrong there is no signal anywhere in the CLI, so a typo is indistinguishable from "this theme just looks like that" — I spent a while adjusting individual colors before realising the base theme had never been applied.
config checkpassing gave me false confidence that the file was correct.Environment