Use Bold To Mean Bold Text Where It Is Currently Ignored

[CannibalVox]

Description of the new feature

Currently, the presence of the bold tag (\e[1m) is used to indicate that one of the original 8 basic colors (30-37) ought to be "bold". The meaning of bold is configurable, but the default is that these colors are promoted to their bright variants. If the color is not 30-37, if it is 256-color, if it is a true-color, the bold tag is ignored, unless the terminal has been configured to use bold text for the bold tag.

This decision was made because this is the original behavior (and is still broadly in use) of the bold tag for the 8 basic colors.

However, under this scheme, using the bold tag in conjunction with a 256-color (for instance \e[0;1;38;5;1) will cause the bold tag to be ignored entirely unless the terminal has been specifically configured otherwise. It is far more common when these tags are used together to use bold text, even in cases where a terminal interprets bold as bright. There's also no downside to interpreting it this way, since there is no expectation that the bold tag will change the color of text being styled with 256-colors or true-colors.

The one downside is what to do when text transitions away from text that was using bold-is-bright into a 256-color. I would argue that there is no real problem with either maintaining the bold styling even in this case, or in not doing so. I assume the former is easier.

Proposed technical implementation details

When the bold tag is active and the text is colored using 256 or truecolor, display bold text.

For instance, the following uses the terminal settings (which by default would make the text bright red):
\e[0;1;31mI am bright red!\e[0m

But the following would display dark red in bold text:
\e[0;1;38;5;1mI am bold dark red!\e[0m

And the following would display bright red in bold text:
\e[0;1;38;5;9mI am bold bright red!\e[0m

The following would display the first portion in bright red and the second portion in bold dark red:
\e[0;1;31mI am bright red! \e[38;5;1mI am bold dark red!\e[0m

[CannibalVox]

FWIW, it's not unusual for certain services to specifically transition to 256-colors even for the original 16 colors in order to signal that it wants bold text without dealing with the ambiguity of bold vs. bright. So the lack of support in windows terminal is a wrench in the works.

[DHowett]

Sorry, I am not sure I understand your proposal. These things are true today if the user enables the bold typeface:

Are you asking for a new (and default) setting where SGR 1 makes colors 0 through 7 (VT 16) brighter only (with no typeface change) and colors 0 through 255 (VT 256) bold (with no intensity change)?

[CannibalVox]

I am asking for the bold typeface to be used for VT 256 and truecolor regardless of configuration settings.

[DHowett]

Got it!

Are there other terminal emulators that work like this? (@j4james may know as well.)

To summarize:

• ANSI 0-7 + SGR 1 = always brighten
• Xterm 0-255 + SGR 1 = always increase font weight
• Xterm true color + SGR 1 = always increase font weight

And that this should be the default?

[CannibalVox]

I don't think that this should be a new config mode, just like "should the italics code work" is not a config mode. The config mode for bold exists because of all the issues around bold vs. bright, but those issues only exist for ANSI 30-37. 256-color and truecolor don't have those problems, so they shouldn't be subject to the config, any more than italics are subject to the config. Adding bold typeface for those two color sets won't have any negative impact on legacy applications and will open up the bold typeface for developers without having to educate users about how to change their appearance settings in WT.

Are there other terminal emulators that work like this?

Most terminals do not default to "bold is bright" like WT. I like that default and I don't want it to change, but the result is that you can't create a bold typeface under any circumstances unless a user changes their settings, which isn't likely to happen. "Bright and bold" and "bold is bold" both have the benefit of being able to set a bold typeface in 256 & truecolor.

iTerm2: Defaults to bright and bold
wezterm on iOS: Works like WT
kitty: forces everyone to "bold is bold" with no configuration 🙄
alacritty: defaults to bold is bold
Terminal.app: defaults to bold is bold

One thing I dislike about "bright and bold" is that it makes it impossible even through 256-color mode to display the first 8 colors with a bold typeface, since it converts them to bright. "Bold is bold" seems like a clear winner, but it makes a lot of legacy applications look bad, which is why I assume that WT uses "bold is bright".

[j4james]

I think this is the default behavior on Mintty, and back when we didn't have any bold font support at all, I was proposing that we should match that behavior. The advantage is that it provides a way for apps to select a bold font explicitly, without breaking backwards compatibility with the standard SGR 1 behavior. I had hoped then that we wouldn't even need an option for bold.

But that proposal was not well received, because the users arguing for bold font support didn't just want some mechanism for selecting bold fonts - they specifically want SGR 1 to mean a bold font (assumedly because that's what they were used to on Linux). And once we had an option for that behavior, there wasn't really a demand for anything else.

I still think the Mintty approach is probably a sensible default, but only if it doesn't make the code more complicated. I don't think we'd need a new option for that.