bold text always renders as white

[walterdejong]

There is an ANSI escape code for rendering bold text: ESC [ 1m
This is supposed to render the text bold or bright in the current foreground color.
mintty seems to always render this text in bright white.

When you choose Foreground color black and Background color white, then any text presented as bold by ESC [ 1m appears invisible/unreadable to the user. Mind that many Linux/UNIX programs use this code to highlight text (e.g, the default settings for man, default settings for colored output of pacman, etc.). mintty becomes unusable with a white or light background.

It doesn't matter what color scheme you use.

Obvious test case to show this issue:

• select Options|Looks|Foreground : black
• select Options|Looks|Background : white
• echo "^[[1mhello^[[0m world" (where ^[ is Ctrl-V ESC)

hello will appear invisible.

• select Options|Looks|Background : blue to reveal the white text

Note

• selecting Options|Text|Show bold xterm will also show it (setting as font and as colour won't)

Currently using mintty 3.6.5 (x86_64-pc-msys) [Windows 19045] installed from msys2

[mintty]

Your report is incomplete. You have likely run wsl inside the window. This is not supposed to be done as wsl runs its own idea of terminal functionality and obstructs proper interaction of the application with the terminal. Use wsltty instead. You could also install wslbridge2 and then invoke mintty --WSL.

[mintty]

See also the lengthy discussions about ConPTY passthrough mode (microsoft/terminal#1173).

[mintty]

To add some detail: wsl has the insane idea that "bold" would mean "bright white". It sets ANSI mode 97 explicitly, which is then correctly interpreted by mintty. You can verify this by choosing any other default colour, the bold foreground will always be white via wsl.
This broken behaviour is clearly a bug of wsl, please report there.

[j4james]

To add some detail: wsl has the insane idea that "bold" would mean "bright white". It sets ANSI mode 97 explicitly,

No it doesn't. That issue was addressed more than 3 years ago. If you're still getting that you must be using a really old version of conpty.

[mintty]

a really old version of conpty

Hmm, thanks for the hint but my Windows version is 22H2 19045. Is ConPTY installed per WSL distribution? How would it be upgraded?

[j4james]

You can bundle a more recent version of the conpty dll with mintty the way wezterm has done (see https://github.com/wez/wezterm/tree/main/assets/windows/conhost), or give users the option to provide the conpty dll themselves similar to what alacritty is doing.

[mintty]

It's possible that you'll need to download this runtime support package from MS in order for this to work: https://www.microsoft.com/en-us/download/details.aspx?id=53175

which I'd need indeed as I don't have its native build environment, but then:

We're sorry, this download is no longer available.

which gets me back to the point that this may be fixed in conhost but the fix is not shipped with Windows, so the whole issue is still a Windows bug.

[j4james]

this may be fixed in conhost but the fix is not shipped with Windows, so the whole issue is still a Windows bug.

I guess you can try reporting this as a bug to Windows, but they'll probably tell you that you need to upgrade to Windows 11. As much as I'd love for Windows 10 to get a more recent version of conhost, I doubt they consider this a high enough priority to be included as a system patch. Anyone that can't upgrade Windows can always switch to a terminal that isn't affected by this issue.