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

[PR #13058] Add support for the DECAC escape sequence #29372

New Issue
Open
opened 2026-01-31 09:34:30 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 09:34:30 +00:00
Owner
Copy Link

Original Pull Request: https://github.com/microsoft/terminal/pull/13058

State: closed
Merged: Yes

The DECAC (Assign Colors) escape sequence controls which color table
entries are associated with the default foreground and background
colors. This is how you would change the default colors on the the
original DEC VT525 terminals.

But DECAC also allows you to assign the color table entries for the
"window frame", which in our case is mapped to the tab color (just the
background for now). So this now gives us a way to control the tab color
via an escape sequence as well.

DETAILS

The way this works is there are now two new entries in the color table
for the frame colors, and two new aliases in the color alias table that
are mapped to those color table entries. As previously mentioned, only
the background is used for now.

By default, the colors are set to INVALID_COLOR, which indicates that
the system colors should be used. But if the user has set a tabColor
property in their profile, the frame background will be initialized with
that value instead.

And note that some of the existing color table entries are now
renumbered for compatibility with XTerm, which uses entries 256 to 260
for special colors which we don't yet support. Our default colors are
now at 261 and 262, the frame colors are 263 and 264, and the cursor
color is 265.

So at runtime, you can change the tab color programmatically by setting
the color table entry at index 262 using OSC 4 (assuming you need a
specific RGB value). Otherwise if you just want to set the tab color to
an existing color index, you can use DECAC 2.

You can even make the tab color automatically match background color by
mapping the frame background alias to the color table entry for the
default background, using DECAC 2;261;262 (technically this is mapping
both the the foreground and background).

This PR doesn't include support for querying the color mapping with
DECRQSS, and doesn't support resetting the colors with RIS, but
hopefully those can be figured out in a future PR - there are some
complications that'll need to be resolved first.

Validation Steps Performed

I've added a basic unit test that confirms the DECAC escape sequence
updates the color aliases in the render settings as expected. I've also
manually confirmed that the tab color in Windows Terminal is updated by
DECAC 2, and the default colors are updated in both conhost and WT
using DECAC 1.

Closes #6574

**Original Pull Request:** https://github.com/microsoft/terminal/pull/13058 **State:** closed **Merged:** Yes --- The `DECAC` (Assign Colors) escape sequence controls which color table entries are associated with the default foreground and background colors. This is how you would change the default colors on the the original DEC VT525 terminals. But `DECAC` also allows you to assign the color table entries for the "window frame", which in our case is mapped to the tab color (just the background for now). So this now gives us a way to control the tab color via an escape sequence as well. DETAILS ------- The way this works is there are now two new entries in the color table for the frame colors, and two new aliases in the color alias table that are mapped to those color table entries. As previously mentioned, only the background is used for now. By default, the colors are set to `INVALID_COLOR`, which indicates that the system colors should be used. But if the user has set a `tabColor` property in their profile, the frame background will be initialized with that value instead. And note that some of the existing color table entries are now renumbered for compatibility with XTerm, which uses entries 256 to 260 for special colors which we don't yet support. Our default colors are now at 261 and 262, the frame colors are 263 and 264, and the cursor color is 265. So at runtime, you can change the tab color programmatically by setting the color table entry at index 262 using `OSC 4` (assuming you need a specific RGB value). Otherwise if you just want to set the tab color to an existing color index, you can use `DECAC 2`. You can even make the tab color automatically match background color by mapping the frame background alias to the color table entry for the default background, using `DECAC 2;261;262` (technically this is mapping both the the foreground and background). This PR doesn't include support for querying the color mapping with `DECRQSS`, and doesn't support resetting the colors with `RIS`, but hopefully those can be figured out in a future PR - there are some complications that'll need to be resolved first. ## Validation Steps Performed I've added a basic unit test that confirms the `DECAC` escape sequence updates the color aliases in the render settings as expected. I've also manually confirmed that the tab color in Windows Terminal is updated by `DECAC 2`, and the default colors are updated in both conhost and WT using `DECAC 1`. Closes #6574
claunia added the pull-request label 2026-01-31 09:34:30 +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 pull-request
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#29372
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?