Skip to content

Add support for OSC 104, 110, 111, 112 and 117 (resets) #18767

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Apr 10, 2025

Conversation

DHowett
Copy link
Member

@DHowett DHowett commented Apr 7, 2025

This pull request adds support for resetting the various color table entries and xterm resource values back to their defaults.

Building on the default color table James introduced in #17879, it was relatively straightforward to add support for resetting specific entries.

This implementation cleaves tightly to observed behavior in xterm(379) rather than observed behavior in libvte(0.70.6). They differ in the following ways:

  • xterm rejects any OSC [110..119] with any number of parameters; libvte accepts it but only resets the first color.
  • When passed a list of color indices to reset in 104, xterm resets any colors up until the first one which fails to parse as an integer and does not reset the rest; libvte resets all parseable color indices.

I was unable to verify how these reset commands interact with colors set via DECAC Assign Color so I went with the implementation that made the most sense:

  • Resetting the background color with 110 also restores the background color alias entry to its pre-DECAC value; this results in the perceived background color returning to e.g. index 0 in conhost and the background color in Terminal.
  • ibid. for the foreground color

Refs #18695
Refs #17879
Closes #3719

DHowett and others added 8 commits March 27, 2025 15:28
this makes resetting the background color the opposite of setting it:
setting it changes the alias to DEFAULT_BACKGROUND, and resetting it
changes it back to INDEX=0 (conhost).

As a side effect, the value of DEFAULT_BACKGROUND is also destroyed.

One could test this in xterm by using DECAC to set the background to
their internal background color index and observing whether it, too, was
preserved.
@DHowett DHowett requested review from lhecker and j4james April 7, 2025 22:29
@microsoft-github-policy-service microsoft-github-policy-service bot added Issue-Task It's a feature request, but it doesn't really need a major design. Area-VT Virtual Terminal sequence support Product-Conhost For issues in the Console codebase labels Apr 7, 2025

This comment has been minimized.

Comment on lines 115 to 117
// Routine Description:
// - Returns one color table entry to the value saved in SaveDefaultSettings.
void RenderSettings::RestoreDefaultColorTableEntries(const size_t startIndex, const size_t count)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment doesn't seem right.

Copy link
Member Author

@DHowett DHowett Apr 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure isn't! Last minute change to take {start, length} rather than just an index :) (thanks!)

Copy link
Collaborator

@j4james j4james left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than the comment nits it looks good to me. I've done some manual testing of the branch and couldn't find any issues. I think matching the Xterm behavior on the edge cases is the right call.

ETA: Also agree with resetting the DECAC values.

@DHowett
Copy link
Member Author

DHowett commented Apr 8, 2025

Thanks for the review, and for the testing! I appreciate it. :)

Copy link
Member

@lhecker lhecker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One nit.

// - Restores a range of color table entries to the values saved in SaveDefaultSettings.
void RenderSettings::RestoreDefaultColorTableEntries(const size_t startIndex, const size_t count)
{
std::copy_n(&_defaultColorTable.at(startIndex), count, &_colorTable.at(startIndex));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like it could use some bounds checks. Perhaps just a std::min together with a soft assert though? Not sure... Alternative we could make it two explicit reset-256-indexed and reset-specific-index functions.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, yeah. I feel weird about this function.

Everywhere else in this file we use .at() and allow the SafeExecute handler to catch the exception. No bounds checks, no worries.

I was so averse to adding members to ITermDispatch that I forgot I could add members to RenderSettings with no real cost.

@github-project-automation github-project-automation bot moved this to To Cherry Pick in 1.23 Servicing Pipeline Apr 9, 2025
@DHowett DHowett moved this from To Cherry Pick to To Consider in 1.23 Servicing Pipeline Apr 9, 2025
@DHowett DHowett moved this from To Cherry Pick to To Consider in 1.22 Servicing Pipeline Apr 9, 2025
@DHowett DHowett merged commit 5f31150 into main Apr 10, 2025
17 of 19 checks passed
@DHowett DHowett deleted the dev/duhowett/reset-colors branch April 10, 2025 00:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-VT Virtual Terminal sequence support Issue-Task It's a feature request, but it doesn't really need a major design. Product-Conhost For issues in the Console codebase
Projects
Status: To Consider
Status: To Consider
Development

Successfully merging this pull request may close these issues.

Support resetting the colors via OSC 104, 110, 111...
3 participants