Pin the terminal default colors to the ayu palette#54
Merged
Conversation
Chrome rows disagreed about painting and many regions rendered on the terminal default, so any host theme other than ayu's bled through as inconsistent banding (see the garish-defaults tui-shot captures). Rather than chasing an explicit background onto every cell, the view now pins the terminal's default background and foreground to ayu via tea.View's BackgroundColor/ForegroundColor, so every unstyled cell lands on the palette by construction. The popup fill keeps deliberately painting no background; it now matches the data area on every terminal. Closes #47 Closes #41 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CS2LZMn2YJdebAiry2jzdP
The palette and View comments claimed unstyled fills match the data area by construction; that holds only on terminals honoring OSC 10/11, so the comments now say what happens elsewhere and on exit. The tui-shot garish-defaults note is re-scoped to what the check verifies since the pin: a regression of the pinning itself, not per-cell styling gaps. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CS2LZMn2YJdebAiry2jzdP
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #47. Closes #41. Stacked on #53 → #52; retarget after those merge.
The garish-defaults captures showed the app relying on the terminal default in many places: data rows, popup fills, status/help text, filler lines. Auditing an explicit background onto every render site is the losing side of that fight — one missed cell reintroduces the bug (the popup fill already shipped that way once).
Instead,
View()now pins the terminal's default colors to the palette (tea.View.BackgroundColor = ayu.bg,ForegroundColor = ayu.fg, i.e. OSC 11/10 for the app's lifetime). Every cell the app does not style explicitly renders on ayu by construction, and #41's design call resolves as "all chrome rows agree" without painting any of them individually. The palette's deliberately-unfilled popup style stays and now matches the data area on any terminal; the stale comment explaining why it couldn't fill is updated.Regression check per #47:
scripts/tui-shotruns on bright-pink/green defaults — captures of the main table, help popup, and query popup show zero bleed-through now (they were mostly pink before).TestViewPinsTerminalDefaultColorsguards the pinning.🤖 Generated with Claude Code
https://claude.ai/code/session_01CS2LZMn2YJdebAiry2jzdP