TUI: set_underline_color: only support colon form #9279

Fixes https://github.com/neovim/neovim/issues/9270

---
Background info per egmontkob:
https://github.com/neovim/neovim/issues/9270#issuecomment-441979176

For undercurl, the newly invented escape sequence is `4:3` strictly with
a colon, as with a semicolon it means single underlined and italic.

For colored underline, the newly invented escape sequence `58:...` is
meant to follow the pattern of `38` and `48`. [ITU
T.416](https://www.itu.int/rec/T-REC-T.416-199303-I/en) § 13.1.8 clearly
specifies the colon only as the separator (and the well-known ECMA-48
§ 8.3.117 just points to this standard).

Using semicolon instead was/is a frequent misinterpretation of this
standard, and is commonly used in the wild – for 38 and 48. More and
more emulators are catching up and beginning to support colon, in
addition to semicolon. Semicolon is pretty fragile; in case an emulator
doesn't recognize a sequence (let's say doesn't recognize the new
extension of `58`), subsequent numbers are interpreted as other
attributes. E.g. if 256-color mode is chosen then the next numeric
parameter is `5` which turns on blinking.

So, luckily, the standard is the technically better solution, the
frequent practice of using semicolons is technically the worse.
Therefore the direction we should be going is clear.

I believe it's a fair requirement for anyone adopting colored underline
to support colons too, and it's a reasonable move from applications to
slightly push the world forward, force developers to catch up with the
recent changes, that is: 1) recognize and at least ignore
colon-delimited parameters even if they aren't supported, 2) recognize
and support colon wherever they support the nonstandard semicolon
instead.

Should you come across any terminal emulator that supports 58 with
semicolons but not with colons, I think the cleanest you can do is
report a bug against them and ignore the problem; they should fix it.

It's yet another common misunderstanding that the truecolor syntax is
`38`/`48`/`58` followed by `:2:rrr:ggg:bbb`. The wording of T.416 is
terrible, but if you read carefully, there's another parameter of
color-space-id preceding the three color channels. Assuming you don't
care about color-space-id, the syntax is `38`/`48`/`58` followed by
`:2::rrr:ggg:bbb` and of course the trailing `m`.

This is only for true-color, the 256-color format doesn't have such
a parameter, it's `38`/`48`/`58` followed by `:5:index` and the final
`m`.

0 files changed, 0 insertions, 0 deletions