Off-by-one in RGB truecolor escape sequence parameter indices
VTE's main developer Christian discovered that pretty much everyone (including iTerm2, and us VTE too) misread/misimplemented the ITU Recommendation T.416 at truecolor escape sequences.
Seen from the comments in iTerm2's source, it expects RGB escape sequences as
CSI 38:2:rrr:ggg:bbb[:unused:tolerance:color_space_for_tolerance] m
and also accepts
CSI 38;2;rrr;ggg;bbb m
(without further optional parameters) for xterm compatibility.
Carefully reading the spec (which only allows ':' as the separator) the actual format is:
CSI 38:2:[color_space_id]:rrr:ggg:bbb[:unused:tolerance:color_space_for_tolerance] m
That is, there's an extra parameter at the beginning before the three color components. For example, to get red=255, green=128, blue=64, the sequence would be
CSI 38:2::255:128:64 m
Most apps that use truecolor emit the xterm-compatible escape sequences, because not too many terminal emulators support ':' as the delimiter, and understandably they choose the easy path which works everywhere. So I wouldn't touch the parameters of the semicolon-based sequence.
With the colon as separator, it would be nice to fix it and adhere to the standard. I'm a bit uncertain if keeping some level of backwards compatibility here (namely: if only three parameters follow the "38:2:" prefix then treat them as R, G, B) is a good idea or not.
Please see the VTE discussion for further details/thoughts.
I'm curious to hear your take on the story, and ideally key players of the story (i.e. popular terminal emulators) would agree on a direction to go.