Support querying the colors via OSC #3718
Comments
egmontkob
added
the
Issue-Feature
ghost
added
Needs-Triage
zadjii-msft
added
Product-Conhost
zadjii-msft
removed
the
Issue-Feature
DHowett-MSFT
removed
the
Needs-Triage
|
I should probably raise a separate issue for this, but I just wanted to note that there are standard DEC sequences for querying the color table (and setting it for that matter) which we may want to support as well. |
|
Note that VTE responds with |
|
I just tested urxvt and it responded with |
|
Well that's awkward. So I have to assume that XTerm has support for Personally I'd prefer |
|
From the XParseColor docs (via the Xterm docs for OSC 4), the RR vs RRR vs RRRR is about the bit-depth of the value. So That said, I guess we don't have native WCG support in Terminal right now, and I expect we'd return the 24-bit colours we are working with, not the tone-mapped resulting colours if we happen to be running on a WCG-based display. So I also support I'm guessing Looks like it was rxvt-specific, and unlike |
|
I've tested the color table queries on 9 different terminal emulators - every one of them (including XTerm , Gnome Terminal, Konsole, and Rxvt) reported the colors as Regarding the other color formats, XTerm does support rgbi and the various cie variants, but the report format is always rgb. |
|
Out of sheer curiosity, what is the reason that makes iTerm2 the weirdest kid in town? CC @gnachman |
|
I believe iTerm2 has an option to choose between reporting as |
|
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. |
|
To be clear, per the spec, both 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 |
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). |
|
That's fair. And given that (for an older version, I didn't check anything newer) xterm
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 ( 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 That said, Microsoft Terminal cannot consume Our local implementation of |
|
I’m working on it. See #7578 if you have time 😄 |
|
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? |
|
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! |
|
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. |
|
Thank you @skyline75489 :) |
This PR merges the default colors and cursor color into the main color table, enabling us to simplify the `ConGetSet` and `ITerminalApi` interfaces, with just two methods required for getting and setting any form of color palette entry. The is a follow-up to the color table standardization in #11602, and a another small step towards de-duplicating `AdaptDispatch` and `TerminalDispatch` for issue #3849. It should also make it easier to support color queries (#3718) and a configurable bold color (#5682) in the future. On the conhost side, default colors could originally be either indexed positions in the 16-color table, or separate standalone RGB values. With the new system, the default colors will always be in the color table, so we just need to track their index positions. To make this work, those positions need to be calculated at startup based on the loaded registry/shortcut settings, and updated when settings are changed (this is handled in `CalculateDefaultColorIndices`). But the plus side is that it's now much easier to lookup the default color values for rendering. For now the default colors in Windows Terminal use hardcoded positions, because it doesn't need indexed default colors like conhost. But in the future I'd like to extend the index handling to both terminals, so we can eventually support the VT525 indexed color operations. As for the cursor color, that was previously stored in the `Cursor` class, which meant that it needed to be copied around in various places where cursors were being instantiated. Now that it's managed separately in the color table, a lot of that code is no longer required. ## Validation Some of the unit test initialization code needed to be updated to setup the color table and default index values as required for the new system. There were also some adjustments needed to account for API changes, in particular for methods that now take index values for the default colors in place of COLORREFs. But for the most part, the essential behavior of the tests remains unchanged. I've also run a variety of manual tests looking at the legacy console APIs as well as the various VT color sequences, and checking that everything works as expected when color schemes are changed, both in Windows Terminal and conhost, and in the latter case with both indexed colors and RGB values. Closes #11768
|
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. |
Specific use-case here: Windows Terminal doesn't yet appear to support querying the background color with ANSI control codes, so vim can't auto-detect whether the background is light or dark and defaults to light mode. microsoft/terminal#3718
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 thergb:RRRR/GGGG/BBBBnotation, and the same terminator (ST vs. BEL) as in the query.Examples:
This allows apps (e.g. vim) to automatically pick a color scheme depending on whether the user has a dark-on-bright on bright-on-dark color scheme. I don't know if it's actually being used in practice, though :D
The text was updated successfully, but these errors were encountered: