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 #22624

New Issue
Open
opened 2026-01-31 08:18:50 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 08:18:50 +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:51 +00:00
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#22624
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?