Consider whether we need to support "bold foreground" (like gnome-terminal) as a separate color

[DHowett-MSFT]

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.

[DHowett-MSFT]

This is intimately tied with the discussion in #109.

[egmontkob]

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]

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]

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;39 brighter 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]

Not sure if I managed to help you, or just confused you more

You know, maybe a little bit of both! 😉

Nah, jokes aside: this is very helpful. Thanks!

[egmontkob]

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)

[jdebp]

The whole idea of font weights and underlines affecting colours comes from the SCO Console (which inspired much of the Linux and FreeBSD kernel terminal emulations) and ECMA-48 control sequence processing that targetted CGA/EGA/VGA display hardware (including the con devices of OS/2 and the MS/PC/DR-DOS ansi.sys); and is a bit of a bodge. (See the various notes about backwards compatibility in screen(HW) in the SCO manual.) It's not something that should be maintained forever into the post-VGA world.

It wasn't in the pre-CGA world, moreover. Real terminals didn't do this, and (ironically) the SCO Console would use proper underlines and boldface when the system had a Monochrome Display Adapter.

This is particularly relevant when it comes to the default colour pair. Its use is often the case for programs that do not generate coloured output. Such programs might well be expecting the monochrome world, where underlines and boldface are actually underlines and boldface.

My softwares maintain font weights and underlines separately from colours in their datastructures, and in the default mode render them as true font weight changes and glyph underlines on screen. There is a non-default mode that can be invoked at the final, realizer, stage (witness the --bold-as-colour option to console-termio-realizer) to convert the font weighting into colour modifications.

This is pretty much the same ideas as M. Koblinger has been propounding, and I am another datum supporting the thesis that there is wide agreement on this nowadays. It's a post-VGA world, and control sequences for font weights, font slants, and underlines are expected to actually do those things.

The places where the VGA behaviour is even used are limited. Old text files with control sequences targetting the con devices of OS/2 and MS/PC/DR-DOS ansi.sys will rely upon this. But the mis-named world of "ANSI Art" has already embraced 24-bit RGB colour long since (reinventing the ITU T.416 SGR sequences badly in one case).

Moreover, the only time when an ncurses/terminfo application will attempt to use boldface and blink as colour changes is if the terminal type is set to linux-16color. It's the only terminal type in the entire terminfo database whose setaf and setab capabilities deal in SGR 1/22 and SGR 5/25. This is most definitely the wrong terminal type for Windows Terminal, and it is unreasonable to expect this as a valid use case. The Linux KVT is notoriously different from XTerm and DEC VTs. The correct response to setting the terminal type to linux-16color with Windows Terminal is don't do that, then.

[chris-morgan]

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]

@chris-morgan That's likely the conpty "narrowing" issue (#2661). I'm fairly certain that plain bold will be passed through as CSI 1 m once that's fixed.

[schuelermine]

Does WT support bold currently? I haven't figured it out. Where can I use it?

[zadjii-msft]

@schuelermine Nope, see #109:

[TBBle]

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]

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]

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]

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. :)