Support querying the colors via OSC #5201

@j4james commented on GitHub (Sep 10, 2020):

I believe iTerm2 has an option to choose between reporting as rgb:rrrr/gggg/bbbb and rgb:rr/gg/bb. They got it wrong initially, and then were forced to add the option to support the correct format because it was breaking in vim.

@j4james commented on GitHub (Sep 10, 2020): I believe iTerm2 has an option to choose between reporting as `rgb:rrrr/gggg/bbbb` and `rgb:rr/gg/bb`. They got it wrong initially, and then were forced to add the option to support the correct format because it was breaking in vim.

claunia commented

@gnachman commented on GitHub (Sep 12, 2020):

I used 8 bit codes originally for reasons I no longer recall. I was made aware of the issue in this post: https://groups.google.com/g/iterm2-discuss/c/xXzeBY2aRjo/m/zHBZreQWCQAJ

Commit 5c5785f3632b8e90dd69f458411a8b8b17aa0599 changed the default to 16 bits. It is now enabled in 3.4.0 betas, which will exit beta when Big Sur is released.

@gnachman commented on GitHub (Sep 12, 2020): I used 8 bit codes originally for reasons I no longer recall. I was made aware of the issue in this post: https://groups.google.com/g/iterm2-discuss/c/xXzeBY2aRjo/m/zHBZreQWCQAJ Commit 5c5785f3632b8e90dd69f458411a8b8b17aa0599 changed the default to 16 bits. It is now enabled in 3.4.0 betas, which will exit beta when Big Sur is released.

claunia commented

@TBBle commented on GitHub (Sep 12, 2020):

To be clear, per the spec, both rgb:rr/gg/bb and rgb:rrrr/gggg/bbbb are valid. So is rgb:rrr/ggg/bbb, and a few other options. The item2-discuss link from @gnachman shows that it was a bug in vim before 8.1, that it incorrectly implemented the XParseColor-compatible colour parser.

That said, the commonality of vim, particularly older vim, means it's probably worth being bug-compatible here from the start, even though it's being overly-precise.

My reading of the Xterm docs for OSC 4 is that if you call OSC 4 XXXX, then OSC 4 ? should be returning precisely that XXXX, but I can see how it can be read to allow returning some numerically-equivalent values, i.e. 48-bit RGB, even if the XXX was originally CIELab:....

@TBBle commented on GitHub (Sep 12, 2020): To be clear, per the spec, _both_ `rgb:rr/gg/bb` and `rgb:rrrr/gggg/bbbb` are valid. So is `rgb:rrr/ggg/bbb`, and a few other options. The item2-discuss link from @gnachman shows that it was a bug in vim before 8.1, that it incorrectly implemented the `XParseColor`-compatible colour parser. That said, the commonality of vim, particularly older vim, means it's probably worth being bug-compatible here from the start, even though it's being overly-precise. My reading of the Xterm docs for OSC 4 is that if you call `OSC 4 XXXX`, then `OSC 4 ?` should be returning precisely that `XXXX`, but I can see how it can be read to allow returning some numerically-equivalent values, i.e. 48-bit RGB, even if the `XXX` was originally `CIELab:...`.

claunia commented

@j4james commented on GitHub (Sep 12, 2020):

My reading of the Xterm docs for OSC 4 is that if you call OSC 4 XXXX, then OSC 4 ? should be returning precisely that XXXX

Yeah, it certainly does read like that. But in practice the spec is defined by the reference implementation, which in this case is XTerm. If you want to be "spec compliant" you need to match whatever XTerm does. And when you think about it, it makes sense for your terminal to be liberal in what it accepts (i.e. supporting as many formats as possible), but conservative in what it produces as a response (you can't reasonably expect every application that queries the palette to understand all the different formats).

@j4james commented on GitHub (Sep 12, 2020): > My reading of the Xterm docs for OSC 4 is that if you call `OSC 4 XXXX`, then `OSC 4 ?` should be returning precisely that `XXXX` Yeah, it certainly does read like that. But in practice the spec is defined by the reference implementation, which in this case is XTerm. If you want to be "spec compliant" you need to match whatever XTerm does. And when you think about it, it makes sense for your terminal to be liberal in what it accepts (i.e. supporting as many formats as possible), but conservative in what it produces as a response (you can't reasonably expect every application that queries the palette to understand all the different formats).

claunia commented

@TBBle commented on GitHub (Sep 13, 2020):

That's fair. And given that (for an older version, I didn't check anything newer) xterm OSC 4 n ? produces XQueryColor formatted as rgb:%04x/%04x/%04x, that seems a safe thing to do.

you can't reasonably expect every application that queries the palette to understand all the different formats

I agree in general. In this case however, because it's not "all the different formats", it's a format defined by a specific API (XParseColor), I would absolutely expect of myself that a parser was prepared to handle those documented formats. Apps on X11 of course have it easy, because they can just use XParseColor, but I'm unaware off-hand of anyone knocking together an X11-independent implementation of the API, which is a shame, but I guess the OSC colour codes are the only, highly-specific use-case for such a thing.

It may not be kind to specify an API behaviour in terms of the API it's implemented with underneath, but that is what we have here. (Edit: If anyone's looking for the implementation side of XParseColor, the colour space parsing is farmed out to functions pointed to by the struct XcmsColorSpace instances, and libXRender separately defines rgba: in XRenderParseColor).

That said, Microsoft Terminal cannot consume rgb:rrrr/gggg/bbbb for OSC 4 right now, so we probably need to fix that, or we end up in the situation where we cannot roundtrip our OSC 4 n ? back to OSC 4 x <string we saved earlier>.

Our local implementation of XParseColor could do with some love too.

@TBBle commented on GitHub (Sep 13, 2020): That's fair. And given that (for an older version, I didn't check anything newer) xterm `OSC 4 n ?` produces [`XQueryColor` formatted as `rgb:%04x/%04x/%04x`](https://github.com/ThomasDickey/old-xterm/blob/master/misc.c#L1334-L1351), that seems a safe thing to do. > you can't reasonably expect every application that queries the palette to understand all the different formats I agree in general. In this case however, because it's not "all the different formats", it's a format defined by a specific API (`XParseColor`), I would absolutely expect *of myself* that a parser was prepared to handle those documented formats. Apps on X11 of course have it easy, because they can just _use_ `XParseColor`, but I'm unaware off-hand of anyone knocking together an X11-independent implementation of the API, which is a shame, but I guess the OSC colour codes are the only, highly-specific use-case for such a thing. It may not be _kind_ to specify an API behaviour in terms of the API it's implemented with underneath, but that is what we have here. (Edit: If anyone's looking for the implementation side of `XParseColor`, the colour space parsing is farmed out to functions pointed to by the [`struct XcmsColorSpace` instances](https://github.com/freedesktop/xorg-libX11/blob/d127217f26df1bf7566c1f372d8b5329a06754ea/src/xcms/Cv.h#L16-L23), and [libXRender separately defines `rgba:`](https://github.com/freedesktop/xorg-libXrender/blob/bce0618839fc33f44edd8b5498b8e33d167806ff/src/Color.c#L33-L74) in `XRenderParseColor`). That said, Microsoft Terminal [cannot _consume_ `rgb:rrrr/gggg/bbbb` for OSC 4 right now](https://github.com/microsoft/terminal/blob/88d1527985123aea66537447241e3fa989fbf755/src/terminal/parser/OutputStateMachineEngine.cpp#L1539-L1548), so we probably need to fix that, or we end up in the situation where we cannot roundtrip our `OSC 4 n ?` back to `OSC 4 x <string we saved earlier>`. Our [local implementation of `XParseColor`](https://github.com/microsoft/terminal/blob/88d1527985123aea66537447241e3fa989fbf755/src/terminal/parser/OutputStateMachineEngine.cpp#L1409-L1420) could do with some love too.

claunia commented

@skyline75489 commented on GitHub (Sep 13, 2020):

I’m working on it. See #7578 if you have time 😄

@skyline75489 commented on GitHub (Sep 13, 2020): I’m working on it. See #7578 if you have time 😄

claunia commented

@mboruta1 commented on GitHub (Apr 8, 2021):

Hello, I am also bumping into this issue. Vim calls OSC 11;? to fetch the terminal's background color when determining what color scheme to use; but because WT does not support fetching this OSC value (only setting it) vim defaults to a color scheme for light terminals.

Is my understanding correct that the outlines of what needs to be done have been laid out but that this feature is not actively under development?

@mboruta1 commented on GitHub (Apr 8, 2021): Hello, I am also bumping into this issue. Vim calls [OSC 11;?](https://github.com/vim/vim/blob/master/src/term.c#L901) to fetch the terminal's background color when determining what color scheme to use; but because WT does not support fetching this OSC value (only setting it) vim defaults to a color scheme for light terminals. Is my understanding correct that the outlines of what needs to be done have been laid out but that this feature is not actively under development?

claunia commented

@zadjii-msft commented on GitHub (Apr 8, 2021):

Yep, that's about the long and short of it. We've already got code elsewhere in the parser for replying to queries, so that can be done. We'd just need conpty to pass through the query through to the connected terminal, and have the terminal reply. Probably wouldn't be that hard, but it's just fairly low down on the backlog currently. We'd happily accept a community contribution though!

@zadjii-msft commented on GitHub (Apr 8, 2021): Yep, that's about the long and short of it. We've already got code elsewhere in the parser for replying to queries, so that can be done. We'd just need conpty to pass through the query through to the connected terminal, and have the terminal reply. Probably wouldn't be that hard, but it's just fairly low down on the backlog currently. We'd happily accept a community contribution though!

claunia commented

2026-01-31 00:07:27 +00:00

@mboruta1 commented on GitHub (Apr 8, 2021):

Ahh, ok, understood. Thank you for the summary! If I have some down time in the next few weeks I will start poking around and putting a PR together.

@mboruta1 commented on GitHub (Apr 8, 2021): Ahh, ok, understood. Thank you for the summary! If I have some down time in the next few weeks I will start poking around and putting a PR together.

claunia commented

@skyline75489 commented on GitHub (Apr 9, 2021):

@mboruta1 I was working on this area previously. The PRs related are #7578 and #8999. It might help you with the “poking around” of the codebase 😃

@skyline75489 commented on GitHub (Apr 9, 2021): @mboruta1 I was working on this area previously. The PRs related are #7578 and #8999. It might help you with the “poking around” of the codebase 😃

claunia commented

2026-01-31 00:07:27 +00:00

@mboruta1 commented on GitHub (Apr 9, 2021):

Thank you @skyline75489 :)

@mboruta1 commented on GitHub (Apr 9, 2021): Thank you @skyline75489 :)

claunia commented

2026-01-31 00:07:27 +00:00

@ClaireCJS commented on GitHub (Jun 6, 2023):

I, too, would love to see this.

I'm cycling colors with a python script, and can't start the color cycle at the existing color without knowing what it is.

Re-creating an old dos program called glow.exe, basically.

@ClaireCJS commented on GitHub (Jun 6, 2023): I, too, would love to see this. I'm cycling colors with a python script, and can't start the color cycle at the existing color without knowing what it is. Re-creating an old dos program called glow.exe, basically.

claunia commented

@rollingmoai commented on GitHub (Aug 24, 2024):

OSC 4, 10, 11 and friends, with a ? instead of a color, respond with the current value of that color in xterm, vte and quite a few other terminals, always using the rgb:RRRR/GGGG/BBBB notation, and the same terminator (ST vs. BEL) as in the query.

Examples:
echo -ne '\e]4;1;?\e\\'; cat

echo -ne '\e]11;?\a'; cat

I'm trying out the latest pre-release (https://github.com/microsoft/terminal/releases/tag/v1.22.2362.0) and these examples don't work? (Git Bash/mintty works however)

@rollingmoai commented on GitHub (Aug 24, 2024): > OSC 4, 10, 11 and friends, with a `?` instead of a color, respond with the current value of that color in xterm, vte and quite a few other terminals, always using the `rgb:RRRR/GGGG/BBBB` notation, and the same terminator (ST vs. BEL) as in the query. > > Examples: > > ``` > echo -ne '\e]4;1;?\e\\'; cat > > echo -ne '\e]11;?\a'; cat > ``` I'm trying out the latest pre-release (https://github.com/microsoft/terminal/releases/tag/v1.22.2362.0) and these examples don't work? (Git Bash/mintty works however)

claunia commented

@rollingmoai commented on GitHub (Feb 14, 2025):

OSC 4, 10, 11 and friends, with a ? instead of a color, respond with the current value of that color in xterm, vte and quite a few other terminals, always using the rgb:RRRR/GGGG/BBBB notation, and the same terminator (ST vs. BEL) as in the query.
Examples:
echo -ne '\e]4;1;?\e\\'; cat

echo -ne '\e]11;?\a'; cat
I'm trying out the latest pre-release (v1.22.2362.0 (release)) and these examples don't work? (Git Bash/mintty works however)

Updates on this? Still doesn't work on the latest stable version (https://github.com/microsoft/terminal/releases/tag/v1.22.10352.0)

@rollingmoai commented on GitHub (Feb 14, 2025): > > OSC 4, 10, 11 and friends, with a `?` instead of a color, respond with the current value of that color in xterm, vte and quite a few other terminals, always using the `rgb:RRRR/GGGG/BBBB` notation, and the same terminator (ST vs. BEL) as in the query. > > Examples: > > ``` > > echo -ne '\e]4;1;?\e\\'; cat > > > > echo -ne '\e]11;?\a'; cat > > ``` > > I'm trying out the latest pre-release ([`v1.22.2362.0` (release)](https://github.com/microsoft/terminal/releases/tag/v1.22.2362.0)) and these examples don't work? (Git Bash/mintty works however) Updates on this? Still doesn't work on the latest stable version (https://github.com/microsoft/terminal/releases/tag/v1.22.10352.0)

claunia commented

@DHowett commented on GitHub (Feb 14, 2025):

@rollingmoai can you provide any more information about the environment you're running these tests in? It works totally fine here on 1.22. See the reports in the background.

If you are using a translation layer such as Cygwin or MSYS2, ensure that TERM is set properly (and that it is not capturing and emulating VT on your behalf.) If you are writing your own application, ensure that you have enabled console modes ENABLE_VIRTUAL_TERMINAL_PROCESSING (output handle) and ENABLE_VIRTUAL_TERMINAL_INPUT (input handle).

@DHowett commented on GitHub (Feb 14, 2025): @rollingmoai can you provide any more information about the environment you're running these tests in? It works totally fine here on 1.22. See the reports in the background. ![Image](https://github.com/user-attachments/assets/89540783-33cc-484f-b4af-6c7e5d72b513) If you are using a translation layer such as Cygwin or MSYS2, ensure that `TERM` is set properly (and that it is not capturing and emulating VT on your behalf.) If you are writing your own application, ensure that you have enabled console modes `ENABLE_VIRTUAL_TERMINAL_PROCESSING` (output handle) and `ENABLE_VIRTUAL_TERMINAL_INPUT` (input handle).

claunia commented