Cloned theme without [colors.selection] gets selection == foreground (invisible highlights)

[errpoulos]

What happened

When a theme installed via omarchy theme install <url> ships no colors.toml and its alacritty.toml has no [colors.selection] block, omarchy-theme-colors-from-alacritty falls back to using the foreground color as the selection background:

https://github.com/basecamp/omarchy/blob/master/bin/omarchy-theme-colors-from-alacritty

background="${COLORS[colors.primary.background]}"
foreground="${COLORS[colors.primary.foreground]}"
selection_background="${COLORS[colors.selection.background]}"
...
selection_background=${selection_background:-$foreground}
...
selection = "$selection_background"

That selection = foreground value then propagates through colors.toml into every downstream template that keys off {{ selection }} / {{ selection_background }} (gum_env.lua.tpl, neovim.lua.tpl via aether.nvim, btop.theme.tpl), since the theme now has a colors.toml, so omarchy-theme-color's own fallback chain (selection -> selection_background -> color8 -> color0 -> background) never gets a chance to kick in for this key — it's already set, just set wrong.

Concretely, on affected themes:

• Neovim: Visual selection and LspReferenceText/LspReferenceRead (the "cursor sitting in a word" highlight) render as invisible text-on-text.
• Interactive gum confirm/gum choose prompts (e.g. omarchy plugin add ... --enable) render the currently-selected yes/no or list item as invisible.
• btop's selected process row (theme[selected_bg]) becomes invisible against main_fg.

Steps to reproduce

1. Install any theme via omarchy theme install <repo> whose alacritty.toml has no [colors.selection] section and ships no colors.toml (e.g. a stripped/minimal alacritty-only theme).
2. omarchy theme set <theme>
3. Inspect the generated colors.toml: selection equals foreground.
4. Open Neovim, do viw on a word, or let an LSP attach and put the cursor on a symbol -> selection/highlight is unreadable.
5. Run any gum confirm/gum choose-based Omarchy command (e.g. omarchy plugin add <url> --enable) -> the highlighted yes/no option is unreadable.

Expected

selection/selection_background should never default to the same value as foreground. A sensible default already exists in the codebase's own fallback chain used elsewhere (color8, else color0, else background) — the alacritty-derivation script should use that same chain instead of $foreground when [colors.selection] is absent.

Fix applied locally

Per-theme workaround: hand-write a colors.toml in ~/.config/omarchy/themes/<name>/ with selection set to that theme's own color8, which pre-empts the buggy generator (it skips generation when colors.toml already exists). Confirmed this fixes both the Neovim and gum symptoms after omarchy theme set. This doesn't fix the generator itself for future/other themes though.

System details

• Omarchy version: 4.0.1-1
• omarchy debug --no-sudo --print available on request

Suggested fix

In bin/omarchy-theme-colors-from-alacritty, change:

selection_background=${selection_background:-$foreground}

to fall back through the same muted/color8 chain omarchy-theme-color already uses elsewhere, e.g.:

selection_background=${selection_background:-${COLORS[colors.bright.black]:-$color8}}

(with an ultimate fallback to $background if even that's unset), so a themed selection background is never identical to the foreground text color.

[fresh3nough]

Opened a fix in #9275.

Root cause matches the report: omarchy-theme-colors-from-alacritty used $foreground when [colors.selection] was missing, so the generated colors.toml locked selection to the text color and every {{ selection }} consumer went invisible.

The PR falls back through color8 -> color0 -> background instead (same cascade as omarchy-theme-color), with a shell test covering the missing-selection and explicit-selection cases.