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.
29 lines
984 B
Fish
29 lines
984 B
Fish
function kitten --description 'Run kitten and restore Kitty theme overrides'
|
|
set -l config_dir "$HOME/.config/kitty"
|
|
if set -q KITTY_CONFIG_DIRECTORY
|
|
set config_dir "$KITTY_CONFIG_DIRECTORY"
|
|
end
|
|
|
|
command kitten $argv
|
|
set -l kitten_status $status
|
|
|
|
# Re-apply the pinned mode over whatever the themes kitten just wrote, and
|
|
# reload so the change shows immediately. apply-theme-mode.sh does the
|
|
# capturing itself, by checksum, so a theme saved through some other route
|
|
# -- `kitty +kitten themes`, a keybinding, another shell -- is picked up on
|
|
# its next run rather than being lost.
|
|
if test $kitten_status -eq 0
|
|
and test (count $argv) -gt 0
|
|
and test "$argv[1]" = themes
|
|
"$HOME/.config/kitty/apply-theme-mode.sh" "$config_dir"
|
|
or return $status
|
|
|
|
if set -q KITTY_WINDOW_ID
|
|
command kitty @ load-config
|
|
or return $status
|
|
end
|
|
end
|
|
|
|
return $kitten_status
|
|
end
|