Repository navigation
Consider whether we need to support "bold foreground" (like gnome-terminal) as a separate color #5682
Description
Many terminals optionally treat \e[1;39m as a separate color.
gnome-terminal has a toggleable "bold foreground" option:
When it's set, 1;39 is different from 39.
Edited to add search keywords: brightForeground bright bold boldForeground
Reacted by Nato Boram, savchenko, Lance Capser, Jonathan Rascher, Arad Alvand, Barnabás Ágoston and bofo540
Activity
DHowett-MSFT commentedon May 1, 2020
This is intimately tied with the discussion in #109.
egmontkob commentedon May 1, 2020
In spirit of our recent cleanups to color handling (multiple issues at one place at gnome-terminal 762247), "bold color" is probably the last one standing that IMO doesn't make any sense and we should start deprecating :-D
egmontkob commentedon May 1, 2020
See also 686043 (italic text color), 104968 (underline text color), reverse color, blink color [these five are supported by xterm: colorBD, colorIT, colorUL, colorRV, colorBL], also xterm's italicULMode which converts underline to italic, maybe there's more.
There are plenty of modes that you could implement, not sure if you should.
I personally find proper bold and italic support much more important.
egmontkob commentedon May 1, 2020
And, to somewhat contradict my previous comments :)
In VTE,
1;39(i.e. bold(bright) combined with the default color) used to make the text brighter, using a hardwired formula (or the explicitly specified color, if enabled, on the settings page you showed).During the recent color cleanup efforts (and let's also link 728600 and 793152 here), this automatic brigtening and the magic hardwired formula were removed from our code.
In other comments I've already spoken up in favor of an optional mode where colors are fully separated from boldness, and such a mode should not make
1;39brighter either. E.g. if a user selects the 16 colors of Solarized, and picks the default fg/bg from this set too, there shouldn't be a 17th color triggered by bold.This, however, requires to have bold typeface, or user-specified explicit bold color. Otherwise SGR 1 becomes a no-op: neither bolder, nor brighter.
(Not sure if I managed to help you, or just confused you more :))
DHowett-MSFT commentedon May 1, 2020
You know, maybe a little bit of both! 😉
Nah, jokes aside: this is very helpful. Thanks!
egmontkob commentedon May 1, 2020
And the IMHO funniest bit:
With Solarized, VTE's magic auto-brightening formula accidentally used to result in almost exactly another Solarized color. That's presumably why no one complained that things were conceptually wrong. (793152 comments 10-11)
1 remaining item
chris-morgan commentedon May 10, 2020
The current behaviour I’m observing in Alacritty, which I believe is coming from ConPTY (though I haven’t exhaustively checked, because that’s an exhausting effort) seems to be that just plain bold (
CSI [ 1 m) turns into bold white (CSI [ 1 ; 38;5;15 m), which is catastrophically wrong for light terminals.This has caused me to give up for now in my attempt to make my terminal light. I had contemplated working around this by swapping “black” and “white” (0 and 7, 8 and 15) but #2661 ruins my Vim colorscheme when 'termguicolors' is enabled (24-bit colour) and I am dispirited and disinclined to bump my colours by one to avoid the problem.
j4james commentedon May 10, 2020
Chris Morgan (@chris-morgan) That's likely the conpty "narrowing" issue (#2661). I'm fairly certain that plain bold will be passed through as
CSI 1 monce that's fixed.schuelermine commentedon Jun 1, 2020
Does WT support bold currently? I haven't figured it out. Where can I use it?
zadjii-msft commentedon Jun 1, 2020
Anselm Schüler (@schuelermine) Nope, see #109:
TBBle commentedon Sep 21, 2020
Is there a meaningful difference between this issue, and resolving #109 in some way? The context here on VTE is particularly useful, but it seems like this issue is a subset of #109 anyway.
zadjii-msft commentedon Sep 21, 2020
Yea #109 is more about the build text weight, while this issue is about the "bold === bright" discussion. IMO they are separate enough issues
TBBle commentedon Sep 21, 2020
Fair 'nuff. So someone could teach the renderer to use a bold font variant to resolve #109, separately from this discussion? Makes sense to me, thanks for the clarification.
bcat commentedon May 5, 2021
Just curious: Is the overall understanding from the Windows Terminal owners that being able to disable the "bold is bright" mapping in the future would be good, and it's just a question of prioritization and blockers? Or is it still undecided if that toggle is a feature worth supporting in the first place?
And, to be clear, I'm asking this independent of what happens with Issue #109. For my personal use cases, it would be lovely if "proper bold" was supported (e.g., for WSL in Windows Terminal), but honestly if I could configure the bold attribute to just be ignored for now that would be incredibly helpful (vs. bold changing text color, which can lead to hard-to-read UIs).
Also, for my own understanding, is this issue just about "bold for the default foreground color" or is it also about "bold for the first 30-37 foreground color escape sequences"? The way I configure my terminals personally is for bold to never become bright, regardless of whether it's the default foreground color, a 30-37 color, a 38 indexed color, or a true color. So as a user I am really hopeful that Windows Terminal will support that behavior some day, even if not right away. :)
Add an ENUM setting for disabling rendering "intense" text as bold (#…
Add an ENUM setting for disabling rendering "intense" text as bold (#…
Consolidate the color palette APIs (#11784)