Accept empty (or nonempty) colorspace in RGB SGR codes

[mitchellh]

Discussed in #4287

^{Originally posted by mnemnion January 1, 2025}
I would consider this a bug, but I do understand the new policy of starting with a discussion.

I was printing RGB colors using this string:

try writer.print(CSI ++ "48:2::{d}:{d}:{d}m", .{ color.r, color.g, color.b });

Note the double colon. Xterm has this to say on the subject:

Ps = 4 8 : 2 : Pi : Pr : Pg : Pb ⇒ Set background color
using RGB values. If xterm is not compiled with direct-color
support, it uses the closest match in its palette for the
given RGB Pr/Pg/Pb. The color space identifier Pi is ignored.

The double colon is just that: an ignored color space, equal to 0 (I think? Could be equal to 1, I'd need to take a closer look at ECMA 48 than is really necessary here). Ghostty does not accept a 0 there either, or any other number (I tried 12 at random). It isn't convenient for me to test with Xterm unfortunately, but WezTerm accepts all of: the double colon, the 0, and 12, as equivalent to leaving out the additional colon (which it has no problem with).

As far as the software I'm writing, I'll drop the second colon, because it seems unlikely to me that the nonstandard version of this code is rejected anywhere, and I'm aiming for broad compatibility (and in fact might have to resort to semicolons, we'll see).

But I think Ghostty should accept Pi in all the standard ways of expressing it, and ignore it, as per ctrlseqs. Who knows? Maybe in the future it will be the first terminal to support colorspaces, it would be pretty neat to have the option of XDR color on Macs.