GNOME Bugzilla – Bug 793152
"OSC 10;color" doesn't affect bold text.
Last modified: 2018-10-19 18:50:52 UTC
The OSC to change the foreground text color doesn't affect bold text. This behavior differs from URxvt, XTerm, ST etc. Here's a test command: printf "%b%s\n%s\n" "\033]10;#ff0000\033\\" "non-bold" "$(tput bold)bold" The expected behavior is that both lines in the output would be red. Instead the bold text retains the terminal's default foreground color (which is usually some shade of white). Is there perhaps another OSC to change the bold text color?
> The expected behavior is that both lines in the output would be red. Indeed. > Instead the bold text retains the terminal's default foreground color Nice catch! It's actually even weirder. Standalone VTE behaves as you describe. Gnome-terminal initially behaves like this, but then on a focus in/out it "fixes" that color to red. > Is there perhaps another OSC to change the bold text color? There's OSC 5;0 for this in xterm, according to my memories not implemented in VTE (I'm not entirely sure about this). There is definitely an API though for the bold color, and gnome-terminal reinstalls the colors via this API on focus in/out (don't ask why). Thanks for the report, I'll take a look.
Let's also mention that an escape sequence color (like OSC 10) is supposed to override the API color, even if the API is invoked later, until the escape sequence color is unset (e.g. OSC 110). See bug 705985 fixed years ago.
Created attachment 367877 [details] [review] Fix, part 1 Automatically constructing the API bold color relied on get_color() which queries the derived (API overridden by ESC) fg+bg colors. This goes against the desired stacking order of the two levels. The current patch fixes it by looking at the API fg+bg colors only. This makes the behavior no longer depend on focus in/out events. The actual bugfix is going to come on top of this.
The simple, clean, easy fix to this bug would be to remove bold color support, as per e.g. bug 762247 comment 1. :-)
Bold color is automatically computed using a crazy formula in vte::color::rgb::rgb(). Looks like it's converting back-n-forth between RGB and YCbCr. This is the first time I ever hear about this latter one. The code dates back to the very early days of VTE, commit 38d95c725. It's irrelevant to this bug, I was just like "what the heck???".
Bug 728600 is pretty closely related, isn't it?
I have the following picture in my mind about our current color handling: #0 #1 ... #255 DEF_FG DEF_BG BOLD_FG ... ESC x x ... x x x x ... API x x ... x x x x ... There are the 256 standard palette colors, plus a few special columns (including DEFAULT_FG, DEFAULT_BG and BOLD_FG). For each we have two slots, the upper ones set/reset by esc sequences (OSC 4/10/11/..., 104/110/111/...), the lower ones set/reset via API. When we need a color, we lookup from top to bottom in its column and pick the first slot that is set. For the standard colors the ESC one is optional, the API one is always set. For the special colors it varies. For FG and BG it's still the same, ESC is optional, API is always set. For highlight and cursor colors (irrelevant now) both are optional, if the lookup doesn't result in a concrete value then we fall back to some special behavior (reversing the cell's fg and bg colors). For BOLD_FG, the ESC slot is always unset because we don't support OSC 5. If we supported, it would set that field. The problem is: BOLD_FG's API field is always set. If the value is cleared via API, a new one is computed based on the (resolved, that is, looked up vertically) DEFAULT_FG and DEFAULT_BG values according to that weird formula and is stored there, exactly as if that particular color was set via API. And this goes against our overall design. If someone sets a BOLD_FG color via API, they sure expect that color to appear on the UI even if they used OSC 10 / 11 for overriding the foregrouond / background colors, as they should be independent. Am I right? So in this case looking up the BOLD_FG color needs to take its API slot. If someone unsets (leaves unset) the BOLD_FG API color, which is the reasonable thing to do, then bold color should be the same as DEFAULT_FG (its ESC or API slot in this order of preference). This is what bug 728600 is about if I'm not confused. In spite of our recent changes to separate the color from boldness as much as possible, is there any remaining rationale for ever auto-creating a bold color? I don't think so. It's either explicitly given via API, or should be the same as the foreground. So as a by-product I guess the crazy YCbCr formula, with a factor of 1.8 from vte.cc could be removed... am I right?
Created attachment 368099 [details] [review] Fix Fix for both this and bug 728600. (Standalone patch, forget the previous one.)
(plus remove the corresponding two lines from vtetypes.hh)
The funny thing is: On Solarized Light, the about-to-be-removed auto bold color is #002835, whereas palette color 8 is #002b36. On Solarized Dark, auto bold color is #ece6e3, while palette color 7 is #eee8d5. They are so damn close that probably that's why Solarized users didn't complain that something was truly wrong here.
... and actually I do have some vague memories from years ago (probably when adding Solarized) noticing the 35 vs 36 difference, I guess I missed the 8 vs B difference there, and attributed it to some rounding error somewhere which I just couldn't care about. I didn't realize that the color should've been a completely different one from the palette :)
(In reply to Egmont Koblinger from comment #7) > In spite of our recent changes to separate the color from boldness [...] In the *spirit* of our recent changes... "In spite of" means the opposite... bad English, sorry :)
Submitted.
(In reply to Dylan Araps from comment #0) > Is there perhaps another OSC to change the bold text color? Shortly after addressing this bug, OSC 5;0 was implemented for vte-0.52.1 in bug 722751.