Catppuccin Latte sets tab_bar_background #BCC0CC, a grey noticeably
darker than its #EFF1F5 background, so in light mode the tab bar sat on
a band of its own colour. kitty.conf leaves the setting commented out --
kitty's default is to follow the terminal background -- but the
generated *-theme.auto.conf files are applied with priority over
kitty.conf, so the theme won and there was nowhere left to override it.
repair-auto-themes.sh already normalises macos_titlebar_color for the
same reason; give tab_bar_background the same treatment. The canonical
copies under theme-modes stay exactly as the themes kitten saved them.
Also picks up the current theme choices: SpaceGray Eighties for dark,
Catppuccin Latte for light.
Saving a theme stopped sticking: the choice was captured only by the fish
`kitten` wrapper, so `kitty +kitten themes`, a keybinding or any non-fish
shell wrote <appearance>-theme.auto.conf directly and the next regeneration
overwrote it from theme-modes. The dark slot had already lost a pick that
way -- dark-theme.auto.conf held #0d0f31 while canonical dark said #2b2c2e.
Move the capture into apply-theme-mode.sh, which every path runs. It records
a cksum of each generated file after the repair step; on the next run a file
whose checksum differs was written by something else, so it becomes canonical
for that appearance. With no state recorded yet nothing is adopted, so a
first run cannot mistake a pinned mode's duplicated files for real choices.
The fish wrapper keeps only its useful part: re-apply the mode and reload so
the change shows at once.
theme-modes/dark.conf is the recovered #0d0f31 (1984). Covered by a new case
in tests/test_theme_mode.sh that writes the theme file with no shell involved.
`kitten themes` treats every .conf in <config-dir>/themes as a user
theme, which the mode system's canonical store was sitting in -- so the
picker was offering three bogus entries named light, dark and
no-preference, and had been since that store was introduced.
Move the store to ./theme-modes so ./themes means only what the kitten
means by it, and repoint apply-theme-mode.sh, the kitten shim, the
run_after hook and the test at the new path.
GrokNight and GrokDay move into ./themes with the ## name/author/
license/upstream/blurb header the kitten reads, so they now show up in
`kitten themes` and `--dump-theme` resolves them.
theme-modes/dark.conf carries the #202020 theme that was already on
disk: the file had to be re-added at its new path, so that drift comes
along with it.
`chezmoi apply` on Linux printed "could not regenerate kitty theme
files" every run. GNU stat reads -f as --file-system, so
`stat -f '%Lp' file` prints a block of filesystem info to stdout and
exits non-zero. The `|| stat -c '%a'` fallback then appended the real
answer to that block, and chmod rejected the result, failing the script
under set -e.
Replace the chain with a file_mode() helper in both scripts: try the GNU
form first, since BSD rejects -c cleanly without printing anything, and
accept the answer only if it is octal. Covered by a new case in
tests/test_theme_mode.sh using a stat stub that reproduces GNU's
behaviour; it fails against the old chain.
kitty gives *-theme.auto.conf priority over everything -- includes and
even --override -- and has no option to stop following the OS. So the
only way to start in a chosen mode is to control what those files
contain. Make them generated:
themes/{light,dark,no-preference}.conf canonical, the real themes
theme-mode auto | light | dark
apply-theme-mode.sh writes the three .auto.conf
Under `auto` each appearance keeps its own theme, so kitty follows the
OS as before. Pinned, all three get the pinned theme, so kitty starts in
it whatever the OS says and a config reload no longer resets it.
`theme` now records the mode and reloads instead of calling set-colors,
which is why the setting survives restarts. A bare `theme` records
`auto` rather than pinning when the toggle lands on the macOS
appearance, so nothing is pinned unless it actually differs.
The kitten shim hashes the automatic theme files before running `kitten
themes` and copies whichever changed into themes/, so picking a new
light theme while pinned to dark is kept and applied on the next switch.
Covered by tests/test_theme_mode.sh.
conf.d/kitty_theme.fish is gone: theme-mode is now the source of truth,
so the universal-variable tracker it maintained is redundant.
__kitty_tab_set sent a luminance-picked black/white active_fg, so a
tinted tab's title looked different from a normal one. Send NONE
instead: tab_fg() then falls back to the shared active foreground (the
theme background) while active_bg keeps the per-host tint.
Covered by a new case in tests/test_tab_bar_colors.py matching what
__kitty_tab_set actually sends — host background, no fg override.
a68b138 made draw_tab() derive all four color roles from tab_colors(),
so it stopped reading the per-tab colors that `kitten @ set-tab-color`
sets. The ssh wrapper (__kitty_tab_set) still set them, but the renderer
discarded them and every remote tab drew in the #2e84e6 accent.
Resolve the drawn colors through DrawData.tab_fg/tab_bg on the already
role-substituted title_draw_data: those return the per-tab override when
one is set and the accent roles otherwise. Theme-provided tab colors
still cannot leak in, so the theme-independence fix is preserved.
Extend tests/test_tab_bar_colors.py with the override case; it fails
against the old renderer (got the accent, wanted the host color).
