-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Support colons as a VT parameter separator #4321
Comments
Does this repro in a legacy console window? (i.e. not wsltty, but Could you link to the
for |
Yeah, the terminfo definition is likely to be the issue here. I'm guessing it's using the colon separator syntax for 24-bit colors which mintty supports but we don't. If that's the case you can just replaces the colons with semicolons in the terminfo file and it should be fine. |
Actually, I've just found the instructions in the Emacs FAQ for setting up the 24bit terminfo (see here). They create two terminfo entries: one using the colon syntax, and one with the semicolon syntax. If those are the instructions you followed, then you can just set your TERM to |
Oh geez. You are correct. I switched to my already defined xterm-24bits and that worked. So yeah, this is not a bug. Maybe a request to indicate if terminfo isn't being parsed correctly due to colons? |
I'm not sure we can generally know that. Alas! |
It's probably worth adding support for the ITU colon syntax to the backlog, though. It may not be as widely used as the semicolon syntax, but it's still worth supporting if possible. |
Let's re-purpose this issue as that thread then 😄 |
See XVilka's gist, in particular:
and of course the spec ITU T.416 itself, too. |
[On a side note... Even after years of developing a terminal, I still keep getting uncertain whether nowadays' most popular terminal description is called |
Pulling the triage tag on this. This seems totally reasonable, and I appreciate your insight on how we shouldn't just treat Thanks! |
I'm working on this. First step is #7220, and the additional delta over switching the VT engine to it is +/- 26/2 lines (not accounting for tests). 😄 |
Since I don't see it mentioned anywhere here, ansi-vte52.sh briefly demonstrates the ITU-T T.416 forms of SGR 38 and SGR 48, including an incorrect form of the truecolour specification (where the colourspace ID was missed) apparently originating from the KDE konsole application, although "pretty much everyone" independently made the same mistake. |
This is an important feature, hopefully it can get some attention. As long as popular terminals don't support the correct syntax it incentivizes everyone to continue building with and relying on the broken syntax. To be honest, it probably should have gone in before 1.0 was declared to minimize the damage. Windows has an oversized influence and so a greater responsibility, just like Spider-man. ;-) |
The ControlSequenceLength function calculates the length of a VT control sequence--used by LengthInBufferCells. SGR control sequences might have parameters, separated by semicolons... or possibly colons. See: microsoft/terminal#4321 This change updates ControlSequenceLength to treat colons similarly to semicolons.
The ControlSequenceLength function calculates the length of a VT control sequence--used by LengthInBufferCells. SGR control sequences might have parameters, separated by semicolons... or possibly colons. See: microsoft/terminal#4321 This change updates ControlSequenceLength to treat colons similarly to semicolons.
I'd love to see this happen soon-ish. I have a bunch of in-house tools that have to support both fancy (256 / truecolor) and limited (16-color only) terminals, and the lack of support for the I can safely use the I can't just detect the terminal type, as large parts of the output are static text files that have been pre-generated. (And I can't justify re-architecting that just for Windows Terminal.) So I'm stuck with only using |
@229c9cf0 Just FYI, there are terminals out there that will simply echo the sequence parameters to the screen when they encounter a colon in an escape sequence, so it's not really that safe. Also, the "correct" syntax for the colon format is actually
I don't know what your target audience is, but in case you aren't aware, Windows Terminal is by no means the only terminal that doesn't support the colon syntax. You can get a general idea of the level of support at this website: https://gist.github.com/XVilka/8346728. But note that it's not always correct, so it's best to confirm for yourself. For example, I'm pretty sure that Konsole doesn't support colons, while more recent versions of Alacritty actually do support colons now. |
Updates for that Gist now go to https://github.com/termstandard/colors, and they also take PRs to fix out of date or wrong info. |
- Fix: Use the colon-separated SGR FG/BG direct color control sequences instead of the semi-colon-separated variation by KDE Konsole.
Perhaps this could be implemented by adding a |
Thanks so much for doing all this work! I'm really excited to dig into your PR. |
Adds support for colon `:` separated sub parameters in parser. Technically, after this PR, nothing should change except, now sub parameters are parsed, stored safely and we don't invalidate the whole sequence when a `:` is received within a parameter substring. In this PR: - If sub parameters are detected with a parameter, but the usage is unrecognised, we simply *skip* the parameter in `adaptDispatch`. - A separate store for sub parameters is used to avoid too many changes to the codebase. - We currently allow up to `6` sub parameters for each parameter, extra sub parameters are *ignored*. - Introduced `VTSubParameters` for easy access to underlying sub parameters. > **Info**: We don't use sub parameters for any feature yet, this is just the core implementation to support newer usecases. ## Validation Steps Performed - [x] Use of sub parameters must not have any effect on the output. - [x] Skip parameters with unexpected set of sub parameters. - [x] Skip sequences with unexpected set of sub parameters. References #4321 References #7228 References #15599 References xtermjs/xterm.js#2751 Closes #4321
Environment
Steps to reproduce
I have TERM set to xterm-24bit using the standard termconfig instructions that are online. Running emacs in terminal mode (emacs -nw) and then using M-x list-display-colors
Behavior (windows terminal on the left, wsltty on the right)
In both cases, emacs knows about all 500+ colors available, but wsltty shows them and windows terminal doesn't. Also this has been like this for a couple months at least, but now it's bugging me enough to ask for a fix. :)
The text was updated successfully, but these errors were encountered: