Coverage decreased (-0.03%) to 33.694% when pulling 4e80317 on whydoubt:true_color into 94c1907 on connectbot:master.

Any update on this one? I see last commit is from March, seems like this project abandoned.

Working perfectly for me, please merge this. The awk script from mRemoteNG/mRemoteNG#717 has the following output:

Coverage decreased (-0.03%) to 33.683% when pulling 3bcc75c on whydoubt:true_color into c3a54a6 on connectbot:master.

Annoyingly I didn't see this change until it was committed.

Ideally the sequences to invoke RGB8 colours should be

SGR 38:2:rrr:ggg:bbb

rather than what will be parsed here, as

SGR 38;2;rrr;ggg;bbb

A lot of terminals have inadvertently used the latter form due ultimately to an annoying quirk of history when someone misread a spec to create it in the very first terminal to implement it. Most terminals are now accepting finally the (correct) former form for it, though that does mean a little extra parsing effort to break sub-parameters on :

I used to work in an ISO TC myself, but that's indeed the funniest ISO vs. de-facto standard story I've came across so far. Anyway, apparently connectbot is in good company and this should be easy to fix. E.g., to accept at least also the correct syntax, adding a case ':': here would be a hot-fix, wouldn't it? Ideally of course, a new state should be introduced instead. Is there any reference implementation?

I used to work in an ISO TC myself, but that's indeed the funniest ISO vs. de-facto standard story I've came across so far. Anyway, apparently connectbot is in good company and this should be easy to fix. E.g., to accept at least also the correct syntax, adding a case ':': here would be a hot-fix, wouldn't it?

Not really. It's not that ; and : are both parameter separators, it's that : is a sub-separator a second level down. The point is that things like

SGR 1;3;38:2:11:22:33;7

splits first at the level of ;, and then at the level of : as a sub-division within that. This would be equivalent to

SGR 1
SGR 3
SGR 38:2:11:22:33
SGR 7

The distinction between ; and : ought to be preserved if the implementation is to be correct. Thing is these :s basically come up nowhere else other than SGR 38, 48, and the super-rare-in-the-wild 58, so in practice hardly anyone bothers :(

Ideally of course, a new state should be introduced instead. Is there any reference implementation?

Reference, I have no idea. I don't know who would possibly by considered authoritative enough to have their implementation called "reference". I could point at my own libvterm, which is mostly the reason why I got involved in ConnectBot in the first place though...

Not really. It's not that ; and : are both parameter separators, it's that : is a sub-separator a second level down. The point is that things like

I understand, but for what's currently supported of the true colour additions, simply adding the case ':' should just work – also for your example (see below). Only when it comes to the unsupported parameters (tolerance, colour space) so that the numbers of arguments can differ, distinguishing between options and sub-options becomes necessary. Or am I missing something? (Taking for granted of course that we don't care about over-accepting and need to accept the de-facto standard ';' (sub-)separators, too.)

Only when it comes to the unsupported parameters (tolerance, colour space) so that the numbers of arguments can differ, distinguishing between options and sub-options becomes necessary. Or am I missing something? (Taking for granted of course that we don't care about over-accepting and need to accept the de-facto standard ';' (sub-)separators, too.)

I believe that is a correct assessment. However, I do have a fairly simple solution in mind that will handle them in more 'correct' way. I just need to actually sit down and write out the code, which I hope to do a few hours from now.

If it's of interest, the way I do this in libvterm is to accept that a given CSI parameter is unlikely to be as high as 2^30, so I use the top bit to remember if this is the non-final of several sub-parameters. If no sub-params happen then no fields get that bit set. For something like SGR 38:2:11:22:33 then all those numbers except the final 33 have the top bit set. To skip to the next (real) parameter then is a matter of doing something like

while(params[i] & (1<<31)) i++;
i++;

This lets you store the sortof-2D shape of params with sub-params efficiently, by accepting that it's rare to have sub-params and burning a tiny little extra CPU to support them by linear search.

When inserting numbers into this array while parsing it's then a simple matter of

case ':'
  (previous param) |= (1<<31);
  /* fallthrough */
case ';'

@leonerd That's almost exactly what I had in mind. I guess that means I had a good idea. ;-)