starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Use Bold To Mean Bold Text Where It Is Currently Ignored #22627

New Issue
Closed
opened 2026-01-31 08:18:54 +00:00 by claunia · 14 comments
claunia commented 2026-01-31 08:18:54 +00:00
Owner
Copy Link

Originally created by @CannibalVox on GitHub (Dec 4, 2024).

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

Originally created by @CannibalVox on GitHub (Dec 4, 2024). ### 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
claunia added the Issue-FeatureArea-RenderingArea-VTNeeds-Tag-FixProduct-Terminal labels 2026-01-31 08:18:54 +00:00
claunia commented 2026-01-31 08:18:55 +00:00
Author
Owner
Copy Link

@CannibalVox commented on GitHub (Dec 4, 2024):

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.

@CannibalVox commented on GitHub (Dec 4, 2024): 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.
claunia commented 2026-01-31 08:18:56 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 4, 2024):

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

Image

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)?

@DHowett commented on GitHub (Dec 4, 2024): Sorry, I am not sure I understand your proposal. These things are true today _if the user enables the bold typeface_: ![Image](https://github.com/user-attachments/assets/562cb7ec-8aae-4d58-bd74-613c3a549624) 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)?
claunia commented 2026-01-31 08:18:56 +00:00
Author
Owner
Copy Link

@CannibalVox commented on GitHub (Dec 4, 2024):

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

@CannibalVox commented on GitHub (Dec 4, 2024): I am asking for the bold typeface to be used for VT 256 and truecolor regardless of configuration settings.
claunia commented 2026-01-31 08:18:56 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 4, 2024):

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?

@DHowett commented on GitHub (Dec 4, 2024): 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?
claunia commented 2026-01-31 08:18:56 +00:00
Author
Owner
Copy Link

@CannibalVox commented on GitHub (Dec 4, 2024):

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".

@CannibalVox commented on GitHub (Dec 4, 2024): 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".
claunia commented 2026-01-31 08:18:56 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Dec 5, 2024):

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.

@j4james commented on GitHub (Dec 5, 2024): 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.
claunia commented 2026-01-31 08:18:57 +00:00
Author
Owner
Copy Link

@tig commented on GitHub (May 12, 2025):

At the maintainer of Terminal.Gui, I need to chime in.

The OP is right. TG now supports TrueColor by default. We are in the middle of adding text styling support for Bold, Italic, etc...

Every contributor who's played with the new PR that introduces the text styling has been stymied to see that Bold was not working. Each, including me, then had to discover and change some buried user setting in WT that makes Bold look just like Normal that's on by default.

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?

I beg the WT team to implement @DHowett's summary, and it real soon now.

Thanks for listening.

@tig commented on GitHub (May 12, 2025): At the maintainer of [Terminal.Gui](https://github.com/gui-cs/Terminal.Gui), I need to chime in. The OP is right. TG now supports TrueColor by default. We are in the middle of adding text styling support for Bold, Italic, etc... Every contributor who's played with the new PR that introduces the text styling has been stymied to see that **Bold** was not working. Each, including me, then had to discover and change some buried user setting in WT that makes **Bold** look just like Normal that's on by default. > 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? I beg the WT team to implement @DHowett's summary, and it real soon now. Thanks for listening.
claunia commented 2026-01-31 08:18:57 +00:00
Author
Owner
Copy Link

@SivanagBalla commented on GitHub (Jun 30, 2025):

@DHowett I continuing the conversation from #19077 here. I understand that bold should be bold. But i have a small issue here.

I have two monitors - one is laptop (2880x1800) 14 inch display and the other is external monitor 1920x1080 24 inch monitor.
On my laptop, the bold text appears like below and it looks good. The bold font is thick enough to distinguish and clear.

Image

But on the other monitor, it looks like this. The bold font is too thick and letters are like touching each other.

Image

I would prefer a option to avoid bold font all together - Let me know your comments and if there's someother option

@SivanagBalla commented on GitHub (Jun 30, 2025): @DHowett I continuing the conversation from [#19077](https://github.com/microsoft/terminal/issues/19077) here. I understand that bold should be bold. But i have a small issue here. I have two monitors - one is laptop (2880x1800) 14 inch display and the other is external monitor 1920x1080 24 inch monitor. On my laptop, the bold text appears like below and it looks good. The bold font is thick enough to distinguish and clear. ![Image](https://github.com/user-attachments/assets/870ed31a-4f80-4e7e-8e5b-26ba56acf9ab) But on the other monitor, it looks like this. The bold font is too thick and letters are like touching each other. ![Image](https://github.com/user-attachments/assets/a0c5e5d5-d7a7-4d6c-8fd9-679b40e72260) I would prefer a option to avoid bold font all together - Let me know your comments and if there's someother option
claunia commented 2026-01-31 08:18:57 +00:00
Author
Owner
Copy Link

@inzeets commented on GitHub (Oct 1, 2025):

What is the suggested way to disable bold fonts after this change? Mintty has simple checkbox for this.

@inzeets commented on GitHub (Oct 1, 2025): What is the suggested way to disable bold fonts after this change? Mintty has simple checkbox for this.
claunia commented 2026-01-31 08:18:57 +00:00
Author
Owner
Copy Link

@ianisl commented on GitHub (Oct 15, 2025):

I second these requests, would it be possible to have a setting to disable this new behavior?

@ianisl commented on GitHub (Oct 15, 2025): I second these requests, would it be possible to have a setting to disable this new behavior?
claunia commented 2026-01-31 08:18:58 +00:00
Author
Owner
Copy Link

@inzeets commented on GitHub (Dec 23, 2025):

WT releases are basically unusable after this update. @SivanagBalla , did you find the alternative?

@inzeets commented on GitHub (Dec 23, 2025): WT releases are basically unusable after this update. @SivanagBalla , did you find the alternative?
claunia commented 2026-01-31 08:18:58 +00:00
Author
Owner
Copy Link

@SivanagBalla commented on GitHub (Dec 24, 2025):

@inzeets I couldn't find alternative. I have set "Intense text style" to "bright colors" which basically disabled bolding.

@SivanagBalla commented on GitHub (Dec 24, 2025): @inzeets I couldn't find alternative. I have set "Intense text style" to "bright colors" which basically disabled bolding.
claunia commented 2026-01-31 08:18:58 +00:00
Author
Owner
Copy Link

@ianisl commented on GitHub (Dec 25, 2025):

@inzeets I mostly had issues with bold styles in Vim, if that's your case too see https://github.com/microsoft/terminal/pull/18903#issuecomment-3406863854 for a granular solution.

@ianisl commented on GitHub (Dec 25, 2025): @inzeets I mostly had issues with bold styles in Vim, if that's your case too see <https://github.com/microsoft/terminal/pull/18903#issuecomment-3406863854> for a granular solution.
claunia commented 2026-01-31 08:18:58 +00:00
Author
Owner
Copy Link

@inzeets commented on GitHub (Dec 28, 2025):

@SivanagBalla , @ianisl , thank you for the hints! Vim based workaround seems to be working: for example, mc launched in vim terminal shows directories in a normal font. They are still bold with "Intense text style" set to "bright colors" (similar to setting it to "None" which stopped working after this update).

@inzeets commented on GitHub (Dec 28, 2025): @SivanagBalla , @ianisl , thank you for the hints! Vim based workaround seems to be working: for example, mc launched in vim terminal shows directories in a normal font. They are still bold with "Intense text style" set to "bright colors" (similar to setting it to "None" which stopped working after this update).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Rendering Area-VT Issue-Feature Needs-Tag-Fix Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#22627
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?