fix(tui): paint the OSC-10 default foreground on quantizing terminals - #72523
Merged
Conversation
A skin that authors a background paints both terminal defaults: OSC-11 for the backdrop, OSC-10 to re-base every default-fg token (markdown body, borders, anything rendered without an explicit color) onto the theme's text tone. The OSC-10 half never fired on a limited-palette terminal. `normalizeThemeForAnsiLightTerminal` rewrites the foreground tones to `ansi256(N)`, and `setTerminalForeground` only accepts `#rrggbb` — so the argument failed the hex test and the write was silently skipped. The background moved to the skin while default-fg text stayed on the host profile's foreground. That split is the reported symptom: prose renders in the terminal's own near-black while every themed token beside it renders the skin's gray, so the base text color appears to change between adjacent words. A resize repaints the affected cells from the screen buffer, which is why the text "goes black" on resize and why the mix looks scattered rather than uniform. Resolve the tone through a new `themeToneHex` before handing it to OSC-10: `ansi256(N)` maps through the xterm grayscale ramp and 6x6x6 cube, an authored hex passes through, and anything with no paintable color yields '' (which correctly clears back to the terminal default). Verified on Terminal.app + the `brooklyn` skin: `theme.color.text` is `ansi256(238)`, previously dropped, now emitted as `ESC]10;#444444 BEL` alongside the existing `ESC]11;#f6f9fd BEL`.
OutThisLife
force-pushed
the
bb/tui-resize-color
branch
from
July 27, 2026 06:59
c71df12 to
0b1ee22
Compare
OutThisLife
enabled auto-merge
July 27, 2026 07:00
Contributor
૮ >ﻌ< ა ci reviewran on 0b1ee22 all good! |
randlee
pushed a commit
to randlee/hermes-agent
that referenced
this pull request
Aug 11, 2026
…-color fix(tui): paint the OSC-10 default foreground on quantizing terminals
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
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.
A skin that authors a background paints both terminal defaults: OSC-11 for the backdrop, OSC-10 to re-base every default-fg token — markdown body, borders, anything rendered without an explicit color — onto the theme's text tone.
The OSC-10 half never fired on a limited-palette terminal.
normalizeThemeForAnsiLightTerminalrewrites the foreground tones toansi256(N), andsetTerminalForegroundonly accepts#rrggbb, so the argument failed the hex test and the write was silently skipped. The background moved to the skin while default-fg text stayed on the host profile's foreground.That split is the reported symptom. Prose renders in the terminal's own near-black while every themed token beside it renders the skin's gray, so the base text color appears to change between adjacent words — and because a resize repaints affected cells from the screen buffer, the text "goes black" on resize and the mix reads as scattered rather than uniform.
This resolves the tone through a new
themeToneHexbefore handing it to OSC-10:ansi256(N)maps through the xterm grayscale ramp and 6×6×6 cube, an authored hex passes through, and a tone with no paintable color yields'', which correctly clears back to the terminal's own default. That keeps the existing opt-in intact — a skin without a background still releases both defaults.Verification
On Terminal.app with the
brooklynskin,theme.color.textresolves toansi256(238). Driving the real paint path through a fake TTY and capturing the bytes:Regression tests are invariant-shaped rather than snapshots: the palette-wide case asserts that every tone in a quantized theme resolves to a literal
#rrggbb, so a newly added tone can't silently regress the paint. Reverting the source fix while keeping the tests turns them red (4 failed), which confirms they actually guard the behavior.tsc --noEmitis clean. The full ui-tui suite has 24 pre-existing failures onorigin/main(subscription overlay, syntax highlighter, backpressure, paired-palette); the failure set is byte-identical before and after this change, so it introduces none.