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 #15469] Add support for Erase Color Mode (DECECM) #30647

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

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

State: closed
Merged: Yes

The Erase Color Mode determines what attributes are written to the
buffer when erasing content, or when new content is scrolled onto the
screen. When the mode is reset (which is the default), we erase with the
active colors, but with rendition attributes cleared. When the mode is
set, we erase with the default attributes, i.e. with neither color nor
rendition attributes applied.

This could be used to address the problem described in issue #10556.

Most of the affected operations are handled within the AdaptDispatch
class, so I've simply updated them all to use a new helper method which
returns the appropriate erase attributes for the active mode.

However, there were a couple of operations that are handled elsewhere,
and which now require the erase attributes to be passed to them as a
parameter.

  • The TextBuffer::IncrementCircularBuffer method, which is used to
    recycle the topmost row when scrolling past the bottom of the buffer.

  • The TextBuffer::SetCurrentLineRendition method, which has to clear
    the second half of the line when switching to a double width rendition.

  • The ITerminalApi::UseAlternateScreenBuffer method, which has to
    clear the screen when switching to the alternate buffer.

Then there is also a Clear Buffer action in Windows Terminal, which is
ultimately handled by the SCREEN_INFORMATION::ClearBuffer method in
ConHost. That class has no access to the erase color mode, so has no way
of knowing which attributes to use. So I've now rewritten it to use the
AdaptDispatch::EraseInDisplay method to handle the erasing.

Validation Steps Performed

I wrote a little test script that exercises the operations affected by
DECECM, which @al20878 kindly tested for us on a real DEC VT525, and
provided screenshots of the output. I've manually confirmed that our
implementation exactly matches those results.

I've also added a unit test that runs through the same set of operations
and verified that each of them is using the appropriate attributes when
DECECM is enabled and enabled.

Closes #14983

**Original Pull Request:** https://github.com/microsoft/terminal/pull/15469 **State:** closed **Merged:** Yes --- The _Erase Color Mode_ determines what attributes are written to the buffer when erasing content, or when new content is scrolled onto the screen. When the mode is reset (which is the default), we erase with the active colors, but with rendition attributes cleared. When the mode is set, we erase with the default attributes, i.e. with neither color nor rendition attributes applied. This could be used to address the problem described in issue #10556. Most of the affected operations are handled within the `AdaptDispatch` class, so I've simply updated them all to use a new helper method which returns the appropriate erase attributes for the active mode. However, there were a couple of operations that are handled elsewhere, and which now require the erase attributes to be passed to them as a parameter. * The `TextBuffer::IncrementCircularBuffer` method, which is used to recycle the topmost row when scrolling past the bottom of the buffer. * The `TextBuffer::SetCurrentLineRendition` method, which has to clear the second half of the line when switching to a double width rendition. * The `ITerminalApi::UseAlternateScreenBuffer` method, which has to clear the screen when switching to the alternate buffer. Then there is also a Clear Buffer action in Windows Terminal, which is ultimately handled by the `SCREEN_INFORMATION::ClearBuffer` method in ConHost. That class has no access to the erase color mode, so has no way of knowing which attributes to use. So I've now rewritten it to use the `AdaptDispatch::EraseInDisplay` method to handle the erasing. ## Validation Steps Performed I wrote a little test script that exercises the operations affected by `DECECM`, which @al20878 kindly tested for us on a real DEC VT525, and provided screenshots of the output. I've manually confirmed that our implementation exactly matches those results. I've also added a unit test that runs through the same set of operations and verified that each of them is using the appropriate attributes when `DECECM` is enabled and enabled. Closes #14983
claunia added the pull-request label 2026-01-31 09:42:05 +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#30647
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?