Been digging into escape sequences lately and gave WezTerm a spin to test some things out
One thing that put a sour taste in my mouth for WezTerm is they document all escape sequences [0] using a deviation from standard syntax (sometimes using `:` over `;` like for RGB colors, at least I've not found any other documentation about this being commonly adopted). They do put a disclaimer at one point in the document but that only helps if you read it linearly and it feels weird to document your implementation of a standard to only work with your terminal, locking people's applications into it.
As for rendering, I had problems with what look like correct escape sequences not rendering correctly (alternative underline styles, colored underlines). I still need to dig further into this where in the stack the problem is (my application or where in WezTerm)
Colon is the correct separator there. Semicolon separates different instructions, a group of values that is a single instruction is colon separated. For example \e[38:5:196;1m specifies red and bold.
Using ";" is popular, and some parsers even require it, but it makes little sense. A terminal that doesn't know about 38 (anything old) will interpret that 5 as blink if you use ";", which is not what anyone wants.
From my experience, the colon separator for 256/rgb attributes is a fairly recent clarification to the spec. I think that's the way it was always supposed to be. But when I was initially writing the 256 color support for the Windows Console about 6 years ago, `TERM=xterm-256color` still emitted colors with just the semicolons as a separator.
The colons are more correct, but the semicolons are seemingly more broadly supported.
I don't recall where I saw it, but my understanding was that : was in the original spec but one of the early implementors (Konsole?) misread it and used ; and that erroneous form is what took off, and here we are today.
Part of the problem is probably that termcap uses : as a separator between capabilities. There is \C for colon, but there are implementations that don't support it. If nothing else I know the termcap[info] command in screen doesn't.
That doesn't stop terminals from supporting it of course, just from saying they do.
Where would I find this documented and how broadly is it supported? So far, the most exhaustive documentation I've found is wikipedia [0], vt100 [2], and wezterm with only wezterm talking about this. I also have not seen `:` handled in the various parsers (e.g. `vte` for alacritty) or generators (e.g. `termcolor`) I've looked at.
If 88- or 256-color support is compiled, the following apply:
[snip]
o The 88- and 256-color support uses subparameters described
in ISO-8613-6 for indexed color. ISO-8613-6 also mentions
direct color, using a similar scheme. xterm supports
that, too.
o xterm allows either colons (standard) or semicolons
(legacy) to separate the subparameters (but after the
first colon, colons must be used).
The indexed- and direct-color features are summarized in the
FAQ, which explains why semicolon is accepted as a
subparameter delimiter:
Can I set a color by its number?
These ISO-8613-6 controls (marked in ECMA-48 5th edition as
"reserved for future standardization") are supported by xterm:
[snip example with colons ":"]
This variation on ISO-8613-6 is supported for compatibility
with KDE konsole:
[snip example with semicolons ";"]
So, the confusion between use of ";" and ":" separators is because the RGB values are not actually parameters (specified as separated by ";"), rather, the RGB values are subparameters (specified as separated by ":"). [Edit #1]
We used semicolon (like other SGR parameters) for separating the R/G/B
values in the escape sequence, since a copy of ITU T.416 (ISO-8613-6)
which presumably clarified the use of colon for this feature was costly.
Using semicolon was incorrect because some applications could expect their
parameters to be order-independent. As used for the R/G/B values, that was
order-dependent. The relevant information, by the way, is part of ECMA-48
(not ITU T.416, as mentioned in Why only 16 (or 256) colors?). Quoting from
section 5.4.2 of ECMA-48, page 12, and adding emphasis (not in the
standard):
[snip]
Of course you will immediately recognize that 03/10 is ASCII colon,
and that ISO 8613-6 necessarily refers to the encoding in a parameter
sub-string. Or perhaps you will not.
:D
[snip]
Later, in 2012 (patch #282), I extended the parser to accommodate the
corrected syntax. The original remains, simply because of its widespread
use. As before, it took a few years for other terminal developers to
notice and start incorporating the improvement. As of March 2016, not
all had finished noticing.
[snip]
* Going forward (e.g., xterm patch #357), these terminfo building blocks
are used in ncurses:
* xterm+256color2 is the building-block for standard terminals
* xterm+256color is a building-block for nonstandard terminals
It's unfortunately seemingly not possible to directly link to the specific text but hopefully that's enough pointers for people to find it themselves.
Once again, seems it's amazing that anything works anywhere. :D
[Edit #1: Corrected from subparameter separator from "," (which is correct for one of the specs I read but incorrect here) to ":".]
It then notes "The column/row notation is used only within Section 6.1 to simplify any cross referencing with applicable ISO standards." :D
A (IMO less effective) description can also be found in ECMA-35 (6th edition; section 5.2 "Code Tables").
(2) A nuance with regard to my "the confusion between use of ';' and ':' separators is because the RGB values are not actually parameters" remark:
The ECMA-48 (5th Edition; section 5.4.2) specification (& ISO/IEC 8613-6 / ITU-T Rec. T.416) talks about "parameter string" & "parameter sub-string" rather than "sub-parameter".
(Also, the "reserved" values mentioned apparently weren't ever actually specified in a standard; and--as noted elsewhere--the format of the ANSI parameter(s) don't exactly match the ODA (ISO/IEC 8613-6 / ITU-T Rec. T.416) format anyway--see ITU-T Rec. T.416 (1993 E) page 41.)
One thing that put a sour taste in my mouth for WezTerm is they document all escape sequences [0] using a deviation from standard syntax (sometimes using `:` over `;` like for RGB colors, at least I've not found any other documentation about this being commonly adopted). They do put a disclaimer at one point in the document but that only helps if you read it linearly and it feels weird to document your implementation of a standard to only work with your terminal, locking people's applications into it.
As for rendering, I had problems with what look like correct escape sequences not rendering correctly (alternative underline styles, colored underlines). I still need to dig further into this where in the stack the problem is (my application or where in WezTerm)
[0] https://wezfurlong.org/wezterm/escape-sequences.html