starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Support colons as a VT parameter separator #6086

New Issue
Closed
opened 2026-01-31 00:29:23 +00:00 by claunia · 19 comments
claunia commented 2026-01-31 00:29:23 +00:00
Owner
Copy Link

Originally created by @atwok on GitHub (Jan 21, 2020).

Originally assigned to: @DHowett on GitHub.

Environment

Windows build number: Microsoft Windows [Version 10.0.19041.21]
Windows Terminal version (if applicable): 0.8.10091.0

Any other software?  WSL, Ubuntu

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)

image

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. :)

Originally created by @atwok on GitHub (Jan 21, 2020). Originally assigned to: @DHowett on GitHub. <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Windows build number: Microsoft Windows [Version 10.0.19041.21] Windows Terminal version (if applicable): 0.8.10091.0 Any other software? WSL, Ubuntu ``` # 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) ![image](https://user-images.githubusercontent.com/26091250/72826584-1d4ab000-3c47-11ea-95ea-369fc31edd49.png) 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. :)
claunia commented 2026-01-31 00:29:25 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 21, 2020):

Does this repro in a legacy console window? (i.e. not wsltty, but conhost.exe running wsl directly)?

Could you link to the

standard termconfig instructions

for xterm-24bit?

@zadjii-msft commented on GitHub (Jan 21, 2020): Does this repro in a legacy console window? (i.e. not wsltty, but `conhost.exe` running `wsl` directly)? Could you link to the > standard termconfig instructions for `xterm-24bit`?
claunia commented 2026-01-31 00:29:25 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 21, 2020):

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.

@j4james commented on GitHub (Jan 21, 2020): 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.
claunia commented 2026-01-31 00:29:25 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 21, 2020):

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 xterm-24bits (with an s) and it should use the semicolon syntax.

@j4james commented on GitHub (Jan 21, 2020): Actually, I've just found the instructions in the Emacs FAQ for setting up the 24bit terminfo (see [here](https://www.gnu.org/software/emacs/manual/html_node/efaq/Colors-on-a-TTY.html)). 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 `xterm-24bits` (with an `s`) and it should use the semicolon syntax.
claunia commented 2026-01-31 00:29:26 +00:00
Author
Owner
Copy Link

@atwok commented on GitHub (Jan 21, 2020):

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?

@atwok commented on GitHub (Jan 21, 2020): 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?
claunia commented 2026-01-31 00:29:26 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jan 21, 2020):

I'm not sure we can generally know that. Alas!

@DHowett-MSFT commented on GitHub (Jan 21, 2020): I'm not sure we can generally know that. Alas!
claunia commented 2026-01-31 00:29:26 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 21, 2020):

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.

@j4james commented on GitHub (Jan 21, 2020): 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.
claunia commented 2026-01-31 00:29:26 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 21, 2020):

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 😄

Relevant:
https://gitlab.com/gnachman/iterm2/issues/6377

@zadjii-msft commented on GitHub (Jan 21, 2020): > 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 😄 Relevant: https://gitlab.com/gnachman/iterm2/issues/6377
claunia commented 2026-01-31 00:29:26 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Jan 21, 2020):

See XVilka's gist, in particular:

  • This comment about why it's important to get the parser right, and why lazy programmer approaches (e.g. treating : as a synonym for ;) are truly harmful;
  • A few comments starting here (Dec 2-5, 2018) how the spec is unclear about the first separator being : or ; (note though that implementations tend to go with : as that clearly makes more sense);

and of course the spec ITU T.416 itself, too.

@egmontkob commented on GitHub (Jan 21, 2020): See XVilka's gist, in particular: - [This comment](https://gist.github.com/XVilka/8346728#gistcomment-2008553) about why it's important to get the parser right, and why lazy programmer approaches (e.g. treating `:` as a synonym for `;`) are truly harmful; - [A few comments starting here](https://gist.github.com/XVilka/8346728#gistcomment-2774523) (Dec 2-5, 2018) how the spec is unclear about the _first_ separator being `:` or `;` (note though that implementations tend to go with `:` as that clearly makes more sense); and of course the spec ITU T.416 itself, too.
claunia commented 2026-01-31 00:29:26 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Jan 21, 2020):

[On a side note... Even after years of developing a terminal, I still keep getting uncertain whether nowadays' most popular terminal description is called xterm-256color or xterm-256colors. Emacs's decision of introducing something that is seemingly a singular vs. plural difference to denote the separator (that final s in xterm-24bits presumably standing for semicolon) was... let's just say probably not a great idea :)]

@egmontkob commented on GitHub (Jan 21, 2020): [On a side note... Even after years of developing a terminal, I still keep getting uncertain whether nowadays' most popular terminal description is called `xterm-256color` or `xterm-256colors`. Emacs's decision of introducing something that is seemingly a singular vs. plural difference to denote the separator (that final `s` in `xterm-24bits` presumably standing for `semicolon`) was... let's just say probably not a great idea :)]
claunia commented 2026-01-31 00:29:27 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jan 23, 2020):

Pulling the triage tag on this. This seems totally reasonable, and I appreciate your insight on how we shouldn't just treat : and ; as equivalent, @egmontkob 😄

Thanks!

@DHowett-MSFT commented on GitHub (Jan 23, 2020): Pulling the triage tag on this. This seems totally reasonable, and I appreciate your insight on how we shouldn't just treat `:` and `;` as equivalent, @egmontkob :smile: Thanks!
claunia commented 2026-01-31 00:29:27 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 9, 2020):

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). 😄

@DHowett commented on GitHub (Aug 9, 2020): 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). :smile:
claunia commented 2026-01-31 00:29:27 +00:00
Author
Owner
Copy Link

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

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.

@TBBle commented on GitHub (Sep 21, 2020): Since I don't see it mentioned anywhere here, [ansi-vte52.sh](https://github.com/csdvrx/sixel-testsuite/blob/31596c68ff960fd45457a6f0d8d86fa5614bc502/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](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h4-Functions-using-CSI-_-ordered-by-the-final-character-lparen-s-rparen:CSI-Pm-m:Ps-=-3-8;2;Pr;Pg;Pb.21AA), although ["pretty much everyone" independently made the same mistake](https://gitlab.com/gnachman/iterm2/-/issues/6377).
claunia commented 2026-01-31 00:29:27 +00:00
Author
Owner
Copy Link

@mixmastamyk commented on GitHub (Oct 3, 2020):

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. ;-)

@mixmastamyk commented on GitHub (Oct 3, 2020): 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. ;-)
claunia commented 2026-01-31 00:29:27 +00:00
Author
Owner
Copy Link

@229c9cf0 commented on GitHub (Sep 12, 2021):

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 : separator means Windows Terminal doesn't get full colors.

I can safely use the \e[...;38:2:R:G:B;...m form and the truecolor part will be ignored as a single unknown control sequence by the old 16-color terminal. But if I were to use ; as a separator, it will instead interpret it as 5 separate control sequences, and then ignore those that it doesn't recognize and interpret the others, and then I end up e.g. with blinking inverted text and stuff like that.

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 : as a separator, and effectively only getting 16 colors on Windows.

@229c9cf0 commented on GitHub (Sep 12, 2021): 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 `:` separator means Windows Terminal doesn't get full colors. I can safely use the `\e[...;38:2:R:G:B;...m` form and the truecolor part will be ignored as a single unknown control sequence by the old 16-color terminal. But if I were to use `;` as a separator, it will instead interpret it as 5 _separate_ control sequences, and then ignore those that it doesn't recognize and interpret the others, and then I end up e.g. with blinking inverted text and stuff like that. 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 `:` as a separator, and effectively only getting 16 colors on Windows.
claunia commented 2026-01-31 00:29:27 +00:00
Author
Owner
Copy Link

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

I can safely use the \e[...;38:2:R:G:B;...m form and the truecolor part will be ignored as a single unknown control sequence by the old 16-color terminal.

@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 38:2::R:G:B. Some terminals support both colon variants, some only support one or the other, but everyone seems to support the semicolon syntax (assuming they support true color at all).

And I can't justify re-architecting that just for Windows Terminal

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.

@j4james commented on GitHub (Sep 12, 2021): > I can safely use the `\e[...;38:2:R:G:B;...m` form and the truecolor part will be ignored as a single unknown control sequence by the old 16-color terminal. @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 `38:2::R:G:B`. Some terminals support both colon variants, some only support one or the other, but everyone seems to support the semicolon syntax (assuming they support true color at all). > And I can't justify re-architecting that just for Windows Terminal 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.
claunia commented 2026-01-31 00:29:28 +00:00
Author
Owner
Copy Link

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

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.

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.

@TBBle commented on GitHub (Sep 13, 2021): > 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. 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.
claunia commented 2026-01-31 00:29:28 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Jun 26, 2023):

Perhaps this could be implemented by adding a bool isSubparameter member to VTParameter, populating that in StateMachine::_ActionParam(const wchar_t wch), and making AdaptDispatch::_ApplyGraphicsOptions skip any subparameters not handled by AdaptDispatch::_ApplyGraphicsOption.

@KalleOlaviNiemitalo commented on GitHub (Jun 26, 2023): Perhaps this could be implemented by adding a `bool isSubparameter` member to `VTParameter`, populating that in `StateMachine::_ActionParam(const wchar_t wch)`, and making `AdaptDispatch::_ApplyGraphicsOptions` skip any subparameters not handled by `AdaptDispatch::_ApplyGraphicsOption`.
claunia commented 2026-01-31 00:29:28 +00:00
Author
Owner
Copy Link

@tusharsnx commented on GitHub (Jul 14, 2023):

Since this is going to be closed after #15648, I've opened a new issue #15706 to track ITU T.416 (inspired) color sequence.

@tusharsnx commented on GitHub (Jul 14, 2023): Since this is going to be closed after #15648, I've opened a new issue #15706 to track ITU T.416 (inspired) color sequence.
claunia commented 2026-01-31 00:29:28 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 15, 2023):

Thanks so much for doing all this work! I'm really excited to dig into your PR.

@DHowett commented on GitHub (Jul 15, 2023): Thanks so much for doing all this work! I'm really excited to dig into your PR.
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 Area-VT Help Wanted In-PR Issue-Task Needs-Tag-Fix Priority-2 Product-Conhost
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#6086
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?