GNOME Bugzilla – Bug 722751
OSC 5 for setting bold color
Last modified: 2020-04-19 23:38:27 UTC
Bold color can currently be set via API, but not via escape sequences. OSC 5;0 (or OSC 4;256) should be able to set/query it, 104/105 should reset. Similar support for underlined color if bug 104968 is addressed.
OSC 5 ; 0 is fine. However OSC 4 ; 256 is a bit problematic. The xterm docs say: Ps = 4 ; c ; spec -> Change Color Number c to the color specified by spec. This can be a name or RGB specification as per XParseColor. Any number of c name pairs may be given. The color numbers correspond to the ANSI colors 0-7, their bright versions 8-15, and if supported, the remainder of the 88-color or 256-color table. If a "?" is given rather than a name or RGB specification, xterm replies with a control sequence of the same form which can be used to set the corresponding color. Because more than one pair of color number and specification can be given in one control sequence, xterm can make more than one reply. Ps = 5 ; c ; spec -> Change Special Color Number c to the color specified by spec. This can be a name or RGB specifica- tion as per XParseColor. Any number of c name pairs may be given. The special colors can also be set by adding the maxi- mum number of colors to these codes in an OSC 4 control: Pc = 0 <- resource colorBD (BOLD). Pc = 1 <- resource colorUL (UNDERLINE). Pc = 2 <- resource colorBL (BLINK). Pc = 3 <- resource colorRV (REVERSE). So for 'bold' to be 256 + 0 that means that the terminal is in 256 colour mode. $ TERM=xterm tput colors 8 $ TERM=xterm-16color tput colors 16 $ TERM=xterm-88color tput colors 88 $ TERM=xterm-256color tput colors 256 (Our default TERM is xterm, but e.g. fedora overrides that to xterm-256color.) It seems xterm does this at compile time, so I guess saying that for vte this is always 256 colour mode is ok?
Yup that's what I thought too, I didn't want to go into such details. One thing to be asked from Thomas: in xterm if you emit 5;0;? the response comes back as 4;256, I think it's a bug.
xterm-314 added OSC 6 which is also relevant. (http://invisible-island.net/xterm/xterm.log.html#xterm_314)
Also need to renumber some of our VTE_*_FG/BG defines so that they're at the right 256 + x value for compat with xterm.
Should also add a comment about this in the source to prevent future breakages, since it's not obvious at all.
Commit e9989360b changed the bold color on color schemes such as "gray on black", it used to be bright white, now it's the same gray as the text. Most VTE-based frontends, including gnome-terminal offer a "bold color" config option, so those who prefer the previous behavior can manually set their desired color. However, at least terminator: https://bugs.launchpad.net/terminator/+bug/1755498 guake: https://github.com/Guake/guake/issues/1208 don't expose this API, meaning that VTE's behavior changed in a way that some users might find unfavorable. Quickly adding OSC 5 support (e.g. for vte-0.52.1) would provide a workaround for them.
(On an unrelated note: when the "bold color" feature kicks in, VTE still renders the text in bold, while xterm uses regular non-bold letters. Meh.)
The fix from the vteparser branch isn't back-portable, but of course a separate implementation could be done for the 0-52 codebase. (In reply to Egmont Koblinger from comment #7) > (On an unrelated note: when the "bold color" feature kicks in, VTE still > renders the text in bold, while xterm uses regular non-bold letters. Meh.) If we want the terminal application to be able to select between bold as attribute and bold as color (like our new API), I think DECSTGLT is the sequence to implement.
> The fix from the vteparser branch isn't back-portable, but of course a > separate implementation could be done for the 0-52 codebase. So, have you already implemented it in your vteparser branch? :) Cool! (What are your plans on submitting it, at least under wip?) > If we want the terminal application to be able to select between bold as > attribute and bold as color (like our new API) I'm not planning to do this (see also bug 762247 comment 13). I'm fine with our current behavior, at least as long as no one complains. (I don't think it's any better or any worse than xterm's, it's just different, and I don't insist on exactly copying xterm everywhere.)
(In reply to Egmont Koblinger from comment #9) > So, have you already implemented it in your vteparser branch? (Yes, see the Whiteboard: entry above.)
Created attachment 369848 [details] [review] Hack Here's a quick hack. It works like xterm in the simplest cases (both 4;256 and 5;0 set the color, both 104;256 and 105;0 reset, querying always reports back as 4;256 [although arguably this is a bug in xterm]). It fails on more complicated ones such as multiple parameters after a 105. I went for what was probably the simplest to code up, without considering such corner cases, nor maintainability of the code, as it will be 0-52 only.
Looks ok. (In reply to Egmont Koblinger from comment #2) > One thing to be asked from Thomas: in xterm if you emit 5;0;? the response > comes back as 4;256, I think it's a bug. I concur that 5 is the correct response, so that's what I do in my branch.
(In reply to Christian Persch from comment #12) > I concur that 5 is the correct response, so that's what I do in my branch. Alright, let's do the same here as well. It's "5;0" so the int->string conversion still needs to be done. To clarify: I guess you mean the response should match the query, so for a 4;256 query the response is still 4;256. (Alternatively, we might say that 4;256 is stupid and we don't support it at all. Would simplify my patch too :))
Yes, reply should be 4;256 when queried from 4, and 5;0 when queried from 5.
Okay to commit with this trivial string change? 0-52 only, or master too and you rebase your stuff?
xterm also resets on parameterless 105, I'll add that too to caps.
(In reply to Egmont Koblinger from comment #15) > Okay to commit with this trivial string change? > > 0-52 only, or master too and you rebase your stuff? Master ok too; I'll just revert before my branch.
> xterm-314 added OSC 6 which is also relevant. > (http://invisible-island.net/xterm/xterm.log.html#xterm_314) I played a little bit with xterm's OSC 106 (aka OSC 6 which conflicts with set-file-uri). The wording of this feature in xterm's changelog and ctlseqs suggests to me that just like OSC 4, 5, 10..19, this would also immediately and retroactively take effect on all existing text. That's not the case, it only marks newly printed text. That is, every bit of bold text carries the information whether it might be affected by the "bold color" feature or not. E.g. if it was printed after an OSC 106;0;1 then a subsequent or preceding OSC 5;0 changes its color, but if it was preceded by an OSC 106;0;0 then not. In case of VTE, we never use VTE_BOLD_FG in the emulation layer (and never store it in vterowdata, ring, stream etc.). If we wanted to implement this feature, we could start using this value for the "106;0;1" case (the default color subject to bold color treatment), and leave VTE_DEFAULT_FG combined with the bold attribute for the "106;0;0" case (a.k.a. I'm just the default color in bold but leave my color alone). [If, theoretically, we wanted to implement this behavior, and extend it to other attributes (underline, blink, reverse and italic color), we'd probably need to allocate 5 bits for the default foreground case. It's doable since we have 25 bits for palette and true colors and the special ones, so we have almost 2^24 values free. It's just a bit of bitpacking.] It's not only the wording of the changelog and ctlseqs that make me suspect that this isn't what xterm intended. 106;0;x firmly corresponds to the colorBDMode resource, and resources are global. Also, emitting an OSC 106;0;x inside a run of bold text doesn't immediately take effect, only when boldness is set/confirmed again with SGR 1. There's also a 106;5;x corresponding to the "resource colorAttrMode (Override ANSI)". Allegedly if set, not only boldness combined with the default fg color, but boldness combined with any explicit SGR foreground color also changes to the given color. I could enable this mode with the colorAttrMode resource, but not via the 106;5;1 escape sequence. [If, theoretically, we wanted to implement this feature, and extend it to the other four attributes, we'd need to add these 5 bits to all currently possible colors, extending the overall struct size. Hell no. Even if we wanted to do this for bold only, it'd require 1 additional bit.] I'd say let's just completely ignore this OSC 106 business.
Comment on attachment 369848 [details] [review] Hack > Master ok too Submitted to master & 0-52. IMO not to be backported any further. No clue how this patch plays without commit e9989360, probably pretty badly, and that patch changes user-facing behavior (which BTW made it desirable to quickly create this patch).
(In reply to Egmont Koblinger from comment #18) > I'd say let's just completely ignore this OSC 106 business. That gets my vote too :-)
(In reply to Christian Persch from comment #12) > > in xterm if you emit 5;0;? the response comes back as 4;256 > > I concur that 5 is the correct response, so that's what I do in my branch. Just for the record: xterm 345 changed to respond with whichever number the query had.