Over ssh the light prompt segments came out lighter than the background
instead of darker. __tide_terminal_background_color learned the
background by reading <appearance>-theme.auto.conf, which on a remote
host belongs to *that* machine: devry pins theme-mode to dark, so
apply-theme-mode.sh writes the dark theme into all three slots there,
including light-theme.auto.conf. Asked for a light background it found
#212121, correctly refused it as contradicting the appearance, ran out of
files and left the caller on its plain-white fallback -- and a segment
derived from white sits above a #EBE8E4 background rather than below it.
Dark was unaffected because that path never recomputes the palette.
Ask the terminal instead, with an OSC 11 query: it is the one source that
describes the window this shell is actually displayed in, whichever
machine the shell runs on. The config files stay as the fallback, where
they are still right, and the static white behind them.
The query costs one 0.2s-bounded read per appearance change, restores the
terminal settings before it can fail, and steps aside under tmux and
screen, which need the query wrapped and each want it wrapped
differently.
Covered by a new live pty scenario that reproduces the ssh case exactly --
config files all dark, terminal reporting light -- which fails on the
previous ordering, plus unit tests for the reply parser and the fallback
chain.
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.
`kitten theme` runs the themes kitten -- kitty accepts unambiguous prefixes
-- but the shim tested `$argv[1] = themes` exactly, so that spelling skipped
the capture and re-apply entirely. Before the theme-mode work that was
harmless, since nothing rewrote the automatic theme files; now the next
regeneration reverts whatever was just chosen, which is why picking a theme
stopped sticking.
Accept any prefix of "themes" at least two characters long. Verified that
themes/theme/them/th all trigger and icat still does not.
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.
Captures the current theme choices in the canonical store: theme-modes/
dark.conf is Galaxy and light.conf is GrokDay, both verified identical
to their source theme files.
`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.
