Colour themes, defaulting to gruvbox dark #1
Reference in New Issue
Block a user
Delete Branch "color-themes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Every colour was a 256-colour ANSI index hardcoded in
styles.go, so changing the palette meant editing the styles themselves. This puts a semantic token set between the two: styles name roles, a theme supplies the colours.What's here
internal/theme— the only place a colour literal exists now.primary,on_primary,text,muted,accent,firing,resolved,error, and four forseverity.gruvbox-dark(the new default) andgruvbox-light.~/.config/terdut-tui/themes/<name>.yaml. A file mayextends:a built-in and override only what it cares about, and may shadow a built-in name to tweak it in place.Config — a
theme:key, empty meaning the default.internal/tui/styles.go— the 21 package-level style vars become aStylesstruct on theModel, which is what architecture rule 3 asked for all along.severityStyle/incidentStatusStylebecome methods; the four free functions inview.gotake aStylesas their first argument.Bubbles components are restyled from the same tokens. Without this a theme would leave a pink selected row and grey help text behind.
Colours are truecolor hex now — lipgloss downsamples for 256- and 16-colour terminals and honours
NO_COLOR, so themes carry no fallbacks of their own. An ANSI index is still accepted for anyone who would rather follow their terminal's own palette.Two things worth a reviewer's eye
The table's
Cellstyle deliberately carries no foreground. Bubbles renders each cell before wrapping the whole row inSelected, so a colour onCellemits a reset mid-row and cuts the selection highlight short after the first character. I hit this, caught it by rendering, and pinned it with a test — please don't "fix" the apparent omission.Themes colour foregrounds only, plus the two inverted spots that need a pair. The app never paints the full alt-screen background, so the terminal supplies the canvas and
gruvbox-darkassumes a dark one. That is the normal contract for a TUI colourscheme, but it is a deliberate choice rather than an oversight.Verification
gofmt,go vet,go test ./...andgo buildare all clean.The rewrite of
view.gowas mechanical: un-renaming the diff reproduces the original line for line, and the style-reference count is unchanged at 104.New tests cover the loader (
extendsmerging, shadowing, missing tokens, unknown keys, malformed colours, path-like names) and the token→style mapping. I checked they aren't vacuous by mutation — reverting the table selection, droppingfiring's bold and breaking theextendsmerge each produce failures. That caught one genuinely vacuous assertion, sinceGetForeground()returnslipgloss.NoColor{}rather thanColor("").Beyond that I rendered real output under a forced truecolor profile to confirm gruvbox reaches the screen, and ran the built binary against a temporary
XDG_CONFIG_HOMEto checkgruvbox-light, a userextends:file, and all four error paths — each exits 1 with a message naming what went wrong.Not tested: the app against a live terdut-server, and
gruvbox-lighton an actual light terminal. The latter is worth a look before merging, since a light scheme is where a poorly chosenmutedshows up first.