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

Consider adding an entry for the default bold color in the color table #16118

New Issue
Closed
opened 2026-01-31 04:57:59 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 04:57:59 +00:00
Owner
Copy Link

Originally created by @j4james on GitHub (Dec 14, 2021).

Description of the new feature/enhancement

At the moment, we when we need to render something using the default foreground color, but with the bold attribute, we "calculate" that brighter color on the fly. Not only does this add unnecessary overhead, but it doesn't even work when the default foreground doesn't match one of the first 8 ANSI colors.

If that bold color was precalculated, though, and stored in the color table, then it's just another index lookup. It would also gives us the architecture necessary to have the bold color part of the color scheme (#5682), and support the XTerm OSC 5 sequence for changing the bold color at runtime.

Finally, I think having bold in the color table is an essential prerequisite for getting the bold color to work when the option to Automaticaly adjust lightness of indistinguishable text is enabled (see #11917).

Proposed technical implementation details (optional)

  1. We add a slot at the end of the color table for the bold color, the same as we've done for the default foreground and background colors.
  2. We have a bold index variable that can either point to that new bold slot, or potentially one of the other positions in the ANSI portion of the table.
  3. If the default foreground index is mapped to one of the first ANSI 8, then the default bold index would be initialized to the corresponding bright index (i.e. plus 8). This would be the typical conhost behavior.
  4. If the default foreground color is unique, we would calculate a brighter version of that color and store it in the new bold slot, and then map the bold index to that slot. This would be the typical WT behavior.

One thing to note on point 4: In the current WT implementation we always treat the default colors as unique, and store them in the separate slots at the end of the table, although in many color schemes they exactly match entries in the first 8 slots. I believe we should really be setting their index to the matching ANSI color (and the bold index then being plus 8), similar to the typical conhost mapping.

One of the advantages of that approach is that it would make it clear when those colors are intended to be the same. For example, if the default background is the same color as ANSI black, then you'd expect a black foreground on a default background to be invisible, and you wouldn't want the algorithm that adjusts the lightness of indistinguishable text to try and make those colors different.

Originally created by @j4james on GitHub (Dec 14, 2021). # Description of the new feature/enhancement At the moment, we when we need to render something using the default foreground color, but with the bold attribute, we "calculate" that brighter color on the fly. Not only does this add unnecessary overhead, but it doesn't even work when the default foreground doesn't match one of the first 8 ANSI colors. If that bold color was precalculated, though, and stored in the color table, then it's just another index lookup. It would also gives us the architecture necessary to have the bold color part of the color scheme (#5682), and support the XTerm OSC 5 sequence for changing the bold color at runtime. Finally, I think having bold in the color table is an essential prerequisite for getting the bold color to work when the option to _Automaticaly adjust lightness of indistinguishable text_ is enabled (see #11917). # Proposed technical implementation details (optional) 1. We add a slot at the end of the color table for the bold color, the same as we've done for the default foreground and background colors. 2. We have a bold index variable that can either point to that new bold slot, or potentially one of the other positions in the ANSI portion of the table. 3. If the default foreground index is mapped to one of the first ANSI 8, then the default bold index would be initialized to the corresponding bright index (i.e. plus 8). This would be the typical conhost behavior. 4. If the default foreground color is unique, we would calculate a brighter version of that color and store it in the new bold slot, and then map the bold index to that slot. This would be the typical WT behavior. One thing to note on point 4: In the current WT implementation we always treat the default colors as unique, and store them in the separate slots at the end of the table, although in many color schemes they exactly match entries in the first 8 slots. I believe we should really be setting their index to the matching ANSI color (and the bold index then being plus 8), similar to the typical conhost mapping. One of the advantages of that approach is that it would make it clear when those colors are intended to be the same. For example, if the default background is the same color as ANSI black, then you'd expect a black foreground on a default background to be invisible, and you wouldn't want the algorithm that adjusts the lightness of indistinguishable text to try and make those colors different.
claunia added the Product-ConhostIssue-TaskArea-VTNeeds-Tag-FixProduct-Terminal labels 2026-01-31 04:58:00 +00:00
claunia commented 2026-01-31 04:58:01 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 14, 2021):

This seems entirely reasonable to me ☺️

@zadjii-msft commented on GitHub (Dec 14, 2021): This seems entirely reasonable to me ☺️
claunia commented 2026-01-31 04:58:02 +00:00
Author
Owner
Copy Link

@PhMajerus commented on GitHub (Dec 14, 2021):

This sounds nice, could even have bold use the user's accent color to fit with the Windows GUI style.
This means we should have a special value in the color scheme JSON to use the current accent color instead of a fixed RGB value, making it change dynamically according to the current user's Windows theme (at least on WT startup, best would be to keep track of it and handle GUI colors changes broadcasts to match any accent color change while WT is in use).

On this topic, it would be nice to have the ability to set a color scheme as a dual color scheme, with one use if the current GUI apps mode is Dark, and the other if it's Light. This would make it possible to have a color scheme with a dark or light background and all other colors tuned according to it, and have it match the other apps dark/light mode.

@PhMajerus commented on GitHub (Dec 14, 2021): This sounds nice, could even have bold use the user's accent color to fit with the Windows GUI style. This means we should have a special value in the color scheme JSON to use the current accent color instead of a fixed RGB value, making it change dynamically according to the current user's Windows theme (at least on WT startup, best would be to keep track of it and handle GUI colors changes broadcasts to match any accent color change while WT is in use). On this topic, it would be nice to have the ability to set a color scheme as a dual color scheme, with one use if the current GUI apps mode is Dark, and the other if it's Light. This would make it possible to have a color scheme with a dark or light background and all other colors tuned according to it, and have it match the other apps dark/light mode.
claunia commented 2026-01-31 04:58:03 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Dec 14, 2021):

This sounds nice, could even have bold use the user's accent color to fit with the Windows GUI style.

Hmmm... I quite like that idea. Not sure how well it would work in practice, but it would interesting to try.

On this topic, it would be nice to have the ability to set a color scheme as a dual color scheme, with one use if the current GUI apps mode is Dark, and the other if it's Light.

This is #4066.

@j4james commented on GitHub (Dec 14, 2021): > This sounds nice, could even have bold use the user's accent color to fit with the Windows GUI style. Hmmm... I quite like that idea. Not sure how well it would work in practice, but it would interesting to try. > On this topic, it would be nice to have the ability to set a color scheme as a dual color scheme, with one use if the current GUI apps mode is Dark, and the other if it's Light. This is #4066.
claunia commented 2026-01-31 04:58:04 +00:00
Author
Owner
Copy Link

@malxau commented on GitHub (Dec 14, 2021):

Is this suggesting that there would be ONE color for bold?

"The SGR parameters 30–37 selected the foreground color, while 40–47 selected the background. Quite a few terminals implemented "bold" (SGR code 1) as a brighter color rather than a different font, thus providing 8 additional foreground colors." (https://en.wikipedia.org/wiki/ANSI_escape_code)

I thought this behavior was sufficiently common/established that a lot of software uses the bold attribute to address the upper 8 colors. It's possible now to access them via 90-97, but how many programs are going to use the older 30-37;1 sequence?

@malxau commented on GitHub (Dec 14, 2021): Is this suggesting that there would be ONE color for bold? "The SGR parameters 30–37 selected the foreground color, while 40–47 selected the background. Quite a few terminals implemented "bold" (SGR code 1) as a brighter color rather than a different font, thus providing 8 additional foreground colors." (https://en.wikipedia.org/wiki/ANSI_escape_code) I thought this behavior was sufficiently common/established that a lot of software uses the bold attribute to address the upper 8 colors. It's possible now to access them via 90-97, but how many programs are going to use the older 30-37;1 sequence?
claunia commented 2026-01-31 04:58:05 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Dec 15, 2021):

Is this suggesting that there would be ONE color for bold?

No. This is just for dealing with the bold version of the default foreground color (i.e. SGR 39).

@j4james commented on GitHub (Dec 15, 2021): > Is this suggesting that there would be ONE color for bold? No. This is just for dealing with the bold version of the default foreground color (i.e. SGR 39).
claunia commented 2026-01-31 04:58:05 +00:00
Author
Owner
Copy Link

@shinmai commented on GitHub (Mar 22, 2023):

but it doesn't even work when the default foreground doesn't match one of the first 8 ANSI colors.

Ahhh, thanks for mentioning this, I just spent the better part of an hour trying to figure out why on earth my colour scheme wasn't working 🤦‍♀️ Setting Foreground to be the same colour as White "fixes" it, but a discrete setting for Foreground and Foreground Bright would be stellar to see at some point.

@shinmai commented on GitHub (Mar 22, 2023): > but it doesn't even work when the default foreground doesn't match one of the first 8 ANSI colors. Ahhh, thanks for mentioning this, I just spent the better part of an hour trying to figure out why on earth my colour scheme wasn't working 🤦‍♀️ Setting Foreground to be the same colour as White "fixes" it, but a discrete setting for Foreground and Foreground Bright would be stellar to see at some point.
claunia commented 2026-01-31 04:58:05 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Oct 30, 2025):

I've just realised that this is a duplicate of #5682.

@j4james commented on GitHub (Oct 30, 2025): I've just realised that this is a duplicate of #5682.
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-VT Issue-Task Needs-Tag-Fix Product-Conhost 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#16118
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?