BTW, with regard to specifying "true" RGB colour related escape codes, note that there's currently a couple of... "issues" with the content in this section: https://www.arp242.net/safeterm.html#true-colours

1. The format of the escape codes given for "True color" is "incorrect"[0], as it "should"[1] use `:` as the separator between the individual red, green & blue values supplied.

2. There is a minor typo/copypesto in "Foreground", where "R" is incorrectly listed twice and "G" is missing.

--- footnotes ---

[0] By "incorrect", I mean "not spec compliant", however, given the author expresses a sentiment of/preference for "I don’t care what some spec says; I care about what works" this presumably motivates their inclusion of the "non spec compliant" form in preference to the strictly spec compliant form[2]. :)

[1] The TLDR being that the entire colour specified by the "RGB" values is a "parameter" (and thus should be separated/surrounded by ";") but the individual "R", "G", "B" values are "parameter sub-strings" (a.k.a. "sub-parameters") and thus "need" to use a different separator: ":", the parameter sub-string separator.

However, for reasons[3], historically ";" was initially incorrectly used by some terminal emulators ("xterm", in particular) as both the parameter separator and the parameter sub-string separator. This error was apparently eventually discovered & corrected in xterm but the correction was not necessarily implemented/propagated to other existing/new terminal emulator implementations--or other tools that parse or generate the colour-related escape codes[4].

[2] This sentiment/preference is not shared by everyone, however, for example, the developer of WezTerm notes in its escape code reference documentation: "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"[8]. :)

[3] Money, or rather, lack thereof. The reason for the original error has been explained as "We [incorrectly] used semicolon [...] for separating the R/G/B values in the escape sequence, since a copy of [the related standard/specification] which presumably clarified the use of colon for this feature was costly."[5][6]

[4] The distinction between use of ";" vs ":" is also not only of "academic"/historic relevance--within the past month (while developing a customization[9] for WezTerm) I ran into an issue caused by spec-compliant vs non-spec-compliant implementations[7] between WezTerm (which generated spec-compliant colour escape codes) and at least some version(s) of `journalctl` which failed to parse & display a log message formatted with the spec-compliant colour and instead displays `[89B blob data]` (by default). This necessitated "munging" the correct escape codes into an incorrect abomination[10] in order for the log message to be formatted & displayed as intended by `journalctl`.

[5] See: https://invisible-island.net/xterm/xterm.faq.html#color_by_n...

[6] For the "Too Long; Did Write:" version of the explanation see the two comments I wrote a year ago when I last fell into this particular rabbit hole, :D here: https://news.ycombinator.com/item?id=35157058 (When the digging leads to learning about the connections to conventions originating in the era of telegraph operators & Morse code, it's probably time to turn around. :D )

[7] To me this suggests one reason to continue using terminfo as a layer of abstraction even when e.g. "all current terminal emulators do the same thing", is that it's one way to reduce the risk of unintentional future deviations in behaviour by existing or new terminal implementations.

[8] The WezTerm escape code reference document is another useful resource for terminal escape code information (written from the perspective of an implementer) that also links to similar reference documents both for other terminal emulator implementations & an attempt to "catch them all": https://wezfurlong.org/wezterm/escape-sequences.html

[9] Reimplementing the Mac Terminal.app ability to display a "faded" scrollback history/context for each tab when restoring a terminal "session"--which is one of only a couple of things that I miss since moving from Mac to Linux as my primary computing environment.

[10] Which was obviously--being the "person of a certain disposition" that I am--both deeply upsetting, and, just, wrong. :D