I have also made V4-patches for the two relevant pieces: the terminfo and ignoring unused grouped arguments.

(file #52927, file #52928)

Replying to comment 3: workaround for missing color was applied to master.

Yes, I know about this, something was changed in ncurses and it seems that tparm ignores 3rd and further parameters, should probably look if there is some workaround or talk to ncurses guy if its intentional.

The problem is: in practice, everyone seems to be using the semicolon format (without color space id). Removing support for this would break the look of currently existing truecolor apps until one day they switch to the correct colon separated (+ color space id) format. Which requires all the terminal emulators to catch up first, then wait for a couple of years so that most users have a new enough terminal emulator.

I'd love to see the whole world fixing it, but if it happens eventually at all (which I cannot guarantee) then it'll take years. And while it's great to have players who "push" the world towards the fix (by starting to reject the old format early on), I'm afraid it might be too early to start that and would cause some users turning away from using screen and/or truecolors.

In case of screen, of course it's two different questions in one: Which formats does it accept as input from apps, and which format does it use towards the host terminal emulator? My proposal: For now, it should accept at least two formats (the popular and the correct one) as input, and emit the popular one towards the host emulator (or have a config option, defaulting to this). Seeing how terminal emulators catch up with the fix, in a couple of years the sequences sent to the host emulator might be flipped to the correct one, and probably not right then but yet another couple of years later support for the old (currently popular) mode could be dropped.

It might also happen that there's not enough motivation in the terminal emulator world to fix it, and we get stuck with the currently frequently used semicolon format forever, I cannot foresee it.

screen accepts 256-color escape sequences like CSI 38;5;INDEXm and truecolor ones like CSI 38;2;R;G;Bm (also with colon as delimiter instead of semicolon). (And similarly 48 for background.)

In fact, screen seems to treat colon and semicolon identically everywhere, e.g. CSI 4:3m switches to underlined(4) and italic(3), just as CSI 4;3m does.

GNOME Terminal developer Christian has recently discovered that pretty much everyone (including xterm, VTE (gnome-terminal), screen etc.) misread/misimplemented the ITU Recommendation T.416 at truecolor escape sequences (and/or copied the false interpretation from each other).

Carefully reading the spec (which only allows ':' as the separator) the actual format is:

  CSI 38:5:INDEXm

and

  CSI 38:2:[color_space_id]:R:G:B[:unused:tolerance:color_space_for_tolerance]m

That is, at truecolor, there's an extra parameter at the beginning before the three color components, plus optional parameters at the end. For example, to get red=255, green=128, blue=64 (an orange-ish color), the sequence could be

  CSI 38:2::255:128:64m

Most apps that support truecolor emit sequences like CSI 38;2;R;G;Bm, because not too many terminal emulators support ':' as the delimiter, and understandably app developers take the easy path which works everywhere. So I wouldn't touch the parameters of the semicolon-based sequence, it'd break existing truecolor support at many places, and there's no way to inject that missing parameter without breaking compatibility with existing (faulty) implementations. I think we should say this format has become the de facto standard.

With the colon as separator, however, it would be nice to fix it and adhere to the de jure standard. That is, take another parameter before the red channel, plus allow optional ones after blue.

For backwards compatibility with the colon-based format and the color_space_id omitted, you may want to still accept only 3 additional parameters after "38:2:" and treat them as R, G and B. But as soon as 4 or more parameters follow "38:2:", the first one should be the color_space_id, then the three color channels, then perhaps further additional ones.

The end of the optional parameters is obviously denoted either by the trailing 'm', or the semicolon ';' which allows further independent SGR attributes to follow.

See https://gist.github.com/XVilka/8346728#gistcomment-2008553 for my opinion about why colon (as stated by the documentation) is a good choice for subparameters and semicolon (in widespread use) is a bad one; and why terminal emulators (such as screen) shouldn't treat them equally.

For more details about this particular issue, please see

https://bugzilla.gnome.org/show_bug.cgi?id=791456

https://gist.github.com/XVilka/8346728#gistcomment-2285644