No colors using xst terminal emulator

[maruimitsuba]

Hi there. I use xst as a terminal emulator. Running tattoy, during the setup stage everything looks to be fine:

But when I then run it afterwards, I see only white text, without any colors:

Running tattoy with the same configuration in emacs vterm works fine (including the color shifting startup logo):

I'll also attach a log file. I don't see anything unusual in it; I don't understand the ERROR messages, but they appear regardless of what terminal emulator I use.

tattoy.log

Thanks for your help, really cool project by the way!

[tombh]

Thanks for the detailed report. This is an interesting bug, the official xterm spec states that the colours in an ANSI colour code should be separated by colons, but by an accident of history there are many terminal emulators (and therefore lots of online examples) that use semicolon separators instead. For example, this is the formal syntax: printf "\033[48:2:255:0:0m!\033[0m", but instead this is often used: printf "\033[48;2;255;0;0m!\033[0m".

So xst uses the semicolons and Tattoy, via its dependency on Wezterm's termwiz library, uses colons.

I finally came across this piece of trivia via a Hacker News thread: https://news.ycombinator.com/item?id=35138390 And there they link to the xterm spec: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html And I also found the Wezterm docs on this:

There are a handful of additional SGR codes that allow setting extended colors; unlike the codes above, which are activated by a single numeric parameter out of SGR sequence, these the extended color codes require multiple parameters. The canonical representation of these sequences is to have the multiple parameters be separated by colons (:), but for compatibility reasons WezTerm also accepts an ambiguous semicolon (;) separated variation. The colon form is unambiguous and should be preferred; the semicolon form should not be used by new applications and is not documented here in the interest of avoiding accidental new implementations.

So I certainly could add a config setting in Tattoy to use semicolons instead of colons, but just wanted to see if you knew much about st? Like would it be worth bringing it up with them? I'm wondering what the best thing to do is with regard to promoting the formal spec. I think at least it'd be worth making sure that st are aware of the situation before implementing a workaround.

[jdebp]

The actual official specification in this instance is a combination of

• ECMA-35, which defines the general form of control sequences and what the 7-bit escape sequence alias for the Control Sequence Introducer character is,
• ECMA-48, which defines the Set Graphic Rendition control sequence, and
• ITU/IEC T.416, which defines how SGR 38 and SGR 48 work to provide more than 8 colours.

People who haven't read ECMA-35 often handle intermediate and parameter characters wrongly, or fail to handle an actual CSI character. People who haven't read ECMA-48 make errors like (for example) not understanding how default to 1 and default to 0 work and when the standards switched to the latter.

People who haven't (carefully) read ITU/IEC T.416 make errors like not doing sub-parameters with colons, and omitting the colour space sub-parameter of SGR 38:2/SGR 48:2 so that every sub-parameter is 1 position off from where it should be. A lot of us made this latter mistake, and it took some years for the correct number of sub-parameters to take hold.

[tombh]

Wow, that's some deep knowledge. Thank you.

[maruimitsuba]

I know the suckless.org people, who develop st, are software perfectionist to a fault, so if st is actually out of spec I think they would be receptive to that. They're known to be hard to deal with for being rather extreme minimalists, but that doesn't seem like it'd be an issue when it comes to "does their program correctly implement the spec or not". If you go to the official webpage for st and click through on the true colors link, you end up here, which has the semicolons in the examples, so I guess that supports the idea that they believe semicolons are the correct syntax for this. (it might be also worth filing an issue there given that they appear to be perpetuating a misunderstanding of the spec)

I can't comment on the specific bug though, terminal emulation is ancient deep magic I know little about ^_^"

[tombh]

Terminals are indeed ancient deep magic, that I'd be surprised that there's anybody that truly understands them!

Okay so looking at the website I think the best first step would be to bring it up on their IRC: irc://irc.oftc.net/#suckless

Interestingly that link to the true colour recommendations repo you gave has a three year old issue about using colons instead of semicolons: termstandard/colors#38. So the fact that that hasn't made it to the README reinforces the point that it's not a critical deviation from the spec. Maybe I should make a PR to get it into the README, it would help in discussing this with st and other projects.