@flybayer, thanks added!

So, finally only one major terminal doesn't have support of true color mode - PuTTY. Any ideas how to reach its developer?

Windows 10 bash terminal now has full support

pantheon-terminal supports true color as well.

Added Patheon Terminal as libvte-based.

LilyTerm removed support for GTK3+ :( Tetralet/LilyTerm@62bbd17

So since terminfo doesn't seem to support true colors, is there any way to check a terminal for true color capability? I need to write a script that outputs either tc colors or just 256 colors, based on the capability of the current terminal.

EDIT:
I actually found that in theory one could test the terminal via DECRQSS by sending DCS $ q m ST, but I could only get this to work in xterm and pangoterm (libvterm). It's a basic VT100 escape sequence but seems to be unsupported by libvte, rxvt and Konsole. At least those are the ones I tested. It's a shame so many terminal emulators identify themselves as xterm, but don't actually support xterm. This solution would be really nice to have, because it doesn't look like terminfo/termcap will support truecolor within the next decade. If you're the maintainer/dev of a terminal emulator and reading this, please consider supporting DECRQSS. That would help a lot for actually programatically determining the color capability of a terminal. There's a seamingly infinite amount of developers and users on Stack Overflow and its forks that are desperate for a way to do this, with no existing solution if you go above 256 colors.

Well, I'm aware there are some unofficial extensions of terminfo http://lists.schmorp.de/pipermail/rxvt-unicode/2016q2/002251.html

Here how you can use it tmux/tmux#34 (comment)

Seems like radare2 also supports true color from what I saw in @s-gilles's post about 24bit true color support in vis in which he links to radare2. I hope @XVilka can at radare2 to this page.

i've published an example C program that shows how one can use the initc terminfo capability to use user-supplied RGB values via ncurses. https://gist.github.com/rofl0r/12c766fc7e72f90cb56daf5d15652fc9 (screenshot: https://0x0.st/pYT.png )
note that this was possible since years with most modern terminals, that support color changing. there's not the true-color terminal escape sequence, most terminals have their own way to use the initc capability. so from that PoV it seems a lot of misinformation is conglomerated here and hyped by people that don't understand the background (which is admittedly rather complex).

also there seems to be a fundamental misunderstanding: that xterm or ncurses supports "only" 256 colors does not mean that it does not support true color. it supports 256 colors that can be displayed at the same time each one with a custom true color 24 bit RGB value.

so it would be much more productive if you told ppl how they can use the initc terminfo cap, and asked upstream developers to support that capability and support a 256 color mode.

@pickfire ofc it suported by radare2 - this is where it all started :)

@rofl0r - still, it prevents the direct RGB SGR sequences, which are vital for programs like radare2, neovim, etc.

@XVilka: why are RGB SGI sequences "vital" for these programs ?

@rofl0r Check out what I wrote a few comments back. That sequence is vital, because it actually lets you and any app in any programming language test the color capability of the terminal emulator it's running in. And I mean actually test it, without assumptions or additional user input or configuration. No environment variables or termcap/-info stuff needed.

It's documented here.

I think Alacritty has truecolor support (based on this comment): https://github.com/jwilm/alacritty

@rofl0r - to be sure that color theme used is always the same among all users, and to eliminate the need to setup palette each time.

@oconnor663 - done, thx!

mlterm is not a libvte-based program. It has original terminal emulation engine.
mlterm provides libvte compatible library. Libvte-based terminals can use that library and run with mlterm's engine.

@xelra What does the output of DCS $ q m ST look like?

Hey, the midnight commander ticket number is misspelled (the link is okay). It's easy to remember: 37_24_ for 24-bit color skins. (Yes, I did deliberately wait for such a nice ticket number :))

@egmontkob thanks, fixed.

For Terminator 1.90, the note "if compiled with GTK+3" is unnecessary. It can only work with GTK+3 and with vte >= 0.38, these are required dependencies.

Also, since it's written in python, it's not "compiled" as the user would think. (It's "compiled" under the hood, not as an explicit step by the user.) So the wording is also debatable. Thanks!

For the "joe" text editor, the feature request is at https://sourceforge.net/p/joe-editor/patches/116/ (yeah I messed it up that I have filed it under "patches", there's no patch yet).

@rofl0r Re your multiple comments, but especially Midnight Commander:

In my opinion, the ideal goal would be to completely get rid of the palette approach. This would allow mcview to display in their full colors (and attributes) text files with ANSI escape sequences (mc bug 1849), mcedit to highlight a color string (e.g. #abcdef) in its exact color, and so on.

mc uses either the ncurses library (which doesn't support truecolors, and its author has made it clear that he won't add support) or slang (which, similarly to ncurses, still has a limited, palette-based truecolor support). See my unanswered question about this on the slang-users mailing list.

My idea of dropping both libraries and coming up our own screen drawing was firmly disliked (mc bug 3264). This could have eliminated this bottleneck, but I understand the reasons nobody wanted to go down this path.

So, in order to be able to use significantly more than the sixty-some color pairs you can define in the skin files, first we'd need to get rid of this bottleneck in the underlying library(-ies) and then further change mc to take advantage of no longer having this constraint. This is absolutely unlikely to happen in the foreseeable future.

As such, in its current (I mean forthcoming, with version 4.8.19) form, mc's truecolor support could be implemented in two ways: either by emitting actual truecolor escape sequences (this is what is implemented), or by fiddling with the palette using the OSC 4 (this is what ncurses's init_color() as well as your code does based on the initc capability). From the simple user's point of view, they would be almost the same. They would probably be the same as long as things work as expected... Hang on...

From the implementation point of view, going for the approach of using the truecolor escape sequences was presumably way easier. At least it was very easy.

The real truecolor support (I mean, where truecolor escape sequences are sent to the terminal emulator) has two drawbacks I can think of. First, it's not supported by all terminal emulators. Indeed, but nor is the other approach. The second is: A bit more data is transferred over the network, serial line etc. In the unlikely case that you're worried about this on your particular setup, you should revert to one of the standard skins, or even black and white. I think it's a non-issue.

You say a reason for the 256-color limit could be to keep the resource allocation reasonable. I don't buy this. Terminal emulators that allow large scrollback buffers should indeed be careful. E.g. VTE (the widget behind GNOME Terminal and many others) uses a runlength encoding of attributes (a continuous region of the same attributes is stored once: 64 bits for the fg+bg colors and all other attributes, and another 64 for the offset of the boundary). Then this stream even gets compressed. For fullscreen apps, or rather, libraries underneath (ncurses, slang) they'd similarly need probably 8 bytes per cell for all the color and attribute information, which, on my laptop, considering e.g. my 239x70 fullscreen terminal, would take 130 kBytes (rather than half of it as they do currently) out of the available 8 or so gigabytes. Not even worth talking about.

Returning to that italic "almost" word, from now on I'll talk about the drawbacks of the other, OSC 4 / initc approach.

We could create a nice support matrix for various terminal emulators whether they support true colors and whether they support OSC 4. But the latter should actually be split to 3 parts: if setting the color with OSC 4 is supported, it is still not sure that OSC 104 for resetting the entry is supported, and that OSC 4 can also query the color. As far as I can remember, there are examples for both of these not being supported even where OSC 4 is available. I'm not sure though, and it might have been older versions.

Wherever truecolor support is missing, it's only a matter of adding this feature (that is, developer laziness/willingness/etc.). We'll see an example where adding OSC 4 is theoretically problematic.

So... first, how do you know if the terminal emulator supports OSC 4? Theoretically you might say you see it from the initc capability. In practice, at least konsole defaults to TERM=xterm (or xterm-256color) which advertises this support, although it doesn't actually support them. That is, you'll get faulty colors in konsole. Okay, let's assume it's fixed.

Obviously, apart from setting the new palette, you'll have to be able to restore the previous. (You need this not only when you quit mc, but also when you toggle the panels on/off, or launch an external command.) How do you do that? There are two ways. Either emit the escape sequence OSC 104 which resets them, or on startup you query the actual colors with OSC 4 and the "?" parameter. Which one would you go for?

How do you know if OSC 104 is supported? Maybe there's a terminfo for that, I don't know.

How do you know if OSC 4 with the "?" attribute to query is supported? OSC commands with the "?" flag suck big time. They are asynchronous, they answer as if the user typed the answer from the keyboard. How long to wait for an answer? Let's say, 1 second, okay? So, if the terminal emulator does not support it, you wait the user for 1 second on each mc startup. Not good. If the terminal supports it, over a slow ssh channel sometimes you'll hit that timeout and mc will not start up with the desired colors. Not good again. Or make mc start up with the default colors, and repaint with the desired skin whenever the response arrives? Terribly user-unfriendly flickering, plus extremely complicated handling of input across all the widgets in mc. Not good again.

Let's note that these two approaches, OSC 104 (reset) and OSC 4 ? (query) (even if we suppose it works reliable, despite just having seen that it theoretically can not) are different. That is, they are different if the user has already altered the palette before starting up mc. In that case 104 would revert to the terminal emulator's default (not the desired behavior), while OSC 4 ? (which, again, cannot be implemented reliably) would revert to the values before starting up mc (the desired behavior).

You scroll up in mc. (Yes, in xterm you can drag the scrollbar with the mouse, even when in application mode.) All the colors there are screwed up.

mc crashes for whatever reason. All the subsequent colors (e.g. "ls -l") will be screwed up. Or you somehow manually fix the palette. Then the remains of mc will look awful.

The ssh channel gets stuck just when you launch or when you quit mc or when you toggle the panels on/off. Due to switching to/from the alternate screen and setting/resetting the palette is not a single atomic step, you might see flickering, or getting stuck for a longer time with faulty colors.

These are the kinds of nightmare you have with the palette approach, everything has an influence on everything else that it shouldn't have.

tmux, some panels next to each other. What should happen, how should tmux communicate the change of palette towards the host terminal emulator? No wonder it does not support them at all. It could always set the palette according to the focused pane, resulting in the other panes always having totally off colors, a terrible user experience. The one I had with X Window and FVWM on my 1024x768 monitor with a 1MB video card until I upgraded to a 2MB video card that could do a fixed 5+6+5 bits instead of a palette. This way 20+ years ago. Or it could translate them to truecolors towards the host emulator. Yes, it could really do it, and I wonder why it doesn't do. But it's another proof of truecolors being way better than the palette nightmare.

Graphical systems, desktops etc. have known for 20+ years now that palettes suck big time, they just can't be made right. In my idealistic opinion, only the RGB colors should remain in terminal emulators, and anyone wishes to have a consistent feeling (e.g. mc's blue being the same as ls's blue), it should be achieved by a common library that these utilities all use. This is what happens at the graphical themes. I know the world is not "ideal" and I know I'm not popular with this idealistic opinion. Don't worry, the legacy 16 / 256 palette colors will stay with us. They are okay. Really, they are really not bad at all. IMO they shouldn't exist, but they do, and they are okay.

Apps redefining them is what's not okay and leads to all kinds of inevitable problems and unreasonable behavior that are simply unexplainable to / unacceptable for the users.

I hope it's clear now why it never occurred to me and would have never implemented truecolor support in mc in a way that's based on modifying the palette. Using the real truecolor escape sequences is the only proper, reliable way. The fact that mc still cannot display more colorpairs at a time than the limit of ncurses/slang is irrelevant and not a valid reason whatsoever to consider the other, braindamaged approach instead. The point of truecolor support is not to suddenly have a crazily colorful UI. The point is to be able to pick any color out of the 16M for any role, and doing this without having an impact on the other colors.

are you sure the color palette for the alternative screen is not separate?
anyway, even the worst-case scenario isn't that bad, because you can typically just refrain from modifying the first 16 colors.
almost no application uses the full palette, and those which do a) can reset the palette themselves and b) you can wrap it into a script that does it.

"are you sure the color palette for the alternative screen is not separate?"
xterm: Tried it and yes, the palette is shared between the two screens.
VTE: I know the codebase well enough to tell for sure without trying that yes, it's also shared here.

@egmontkob: will fix today. Yes. making a separate table, or updating this one, separating the colors calculation/ability to show and the ability to use direct RGB sequence.

And maybe it's time to make it's a repository, to be able to have multiple contributors, accept pull requests and so on.

One more thing, could you please add a section about how to detect if a terminal emulator supports true colors? Something along these lines:

There's no reliable way, and ncurses/terminfo's maintainer expressed he has no intent on introducing support. S-Lang author added a check for $COLORTERM containing either "truecolor" or "24bit" (case sensitive). In turn, VTE, Konsole and iTerm2 set this variable to "truecolor" (it's been there in VTE for a while, it's relatively new and maybe still git-only (I haven't checked) in Konsole and iTerm2).

This is obviously not a reliable method, and is not forwarded via sudo, ssh etc. However, whenever it errs, it errs on the safe side: does not advertise support whereas it's actually supported. I don't think there's a way it could err on the other side, I'm not sure though.

App developers can freely choose to check for this same variable, or introduce their own method (e.g. an option in their config file), whichever matches better the overall design of the given app. I personally recommend checking $COLORTERM since that would lead to a more unique desktop experience where the user has to set one variable only and it takes effect across all the apps, rather than something separately for each app.

@egmontkob: Done, will make a repo this weekend.

Hi, emacs has now learned 24bit colors, though it requires custom terminfo
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e463e57
Here's the thread. The discussion continues to this month.
https://lists.gnu.org/archive/html/emacs-devel/2016-08/msg00711.html

@holomorph: Awesome news! Thanks, added it.

For what it's worth, terminfo will probably never be updated to support truecolors.

I suggest we stop asking him, his mind is set and apparently some people have harassed him about this (in private, I guess?).

Let's see if we can come up with something reasonable in https://bugzilla.gnome.org/show_bug.cgi?id=778958.

@egmontkob

tmux uses Tc to mark terminfo entries for terminals that support RGB colours. Assuming I understood correctly, entries with leading upper and then lower case are considered extensions. Tc has made it to the terminfo database in the entry for st but you may need luck to get it added to any of the other entries.

FWIW if everyone standardizes on a different, sensible solution, I will use it.

For me, this means it must use terminfo, so not an environment variable.

emacs' setf24/setb24 is a reasonable idea, but I would strongly recommend changing it to accept three separate R,G,B parameters like conventional terminfo capabilities. Since they have done it already, perhaps set24f/set24b for a fixed version instead (which matches setaf/setab anyway).

A few other things it may be worth noting:

• I expect that we (OpenBSD) would be willing to add entries for RGB colour to our terminfo database, of course assuming they are sensible and OpenBSD users need them. We already have local changes, for example for rxvt-unicode.

• The main reason I would recommend using 3 parameters rather than 1 is that using a weird capability form is just throwing up unnecessary roadblocks in front of something where there is already considerable resistance from upstream.

• I personally would (and will) forget about the colon form entirely, it is silly.

• The reason I chose a flag (Tc) was that it is easier for users to manage than a pair of long, complex sequences. And this is not a feature with historical baggage where here will be terminals that use different sequences to do the same thing, only modern terminals will support this and they would be silly not to use the same escape sequences as everyone else.

$COLORTERM is no longer git-only in Konsole

@nicm

I'm completely with you on using terminfo (rather than some env var), three separate parameters (I can't see a valid reason for squeezing them into one), and even the set24f/set24b naming (or whatever else that looks kinda sensible -- what does "a" stand for in setaf/setab?).

I don't get the Tc bits, what's that? Is that a boolean terminfo flag whose presence denotes truecolor support? If so, why do we need such a flag rather than looking for the presence/absence of set24f (or whichever we settle with) itself? Or is it instead of set24f/set24b so that every app would have to hardcode the actual sequences? I don't like this idea that much.

The colon form is not silly, it is a great idea for forward compatibility if and only if implemented correctly in terminal emulators -- alas it is not in quite a few. As such I guess we should go for semicolons here (so with that I agree with you).

@XVilka

The page says konsole supports both colon and semicolon. The linked bugreport where konsole handled this issue has long discussions about it. I've tried it though and it doesn't work (konsole version 16.04.3 on Ubuntu 16.10). Not sure if it was never actually implemented, or broke at some point.

@dequis @jerch @rdebath Returning to your old question/answers about semicolons and colons:

What I believe is the main reason is forward compatibility. jerch's response was the closest to that, but I don't think ease of implementation should matter (in fact, implementing support for colons was really nontrivial in VTE).

Let's take this example: \e[38;2;3;4;5;7m.

The main question is: How does a terminal emulator that does not (yet) support truecolors know where the subparameters to "38;2" end and "normal" parameters resume? How does it know that it should not start italic (3), underlined (4), blinking (5) mode but it should render in reverse (7)? In order to know it, it has to know at least that "38;2" takes three additional parameters.

Same question for all the emulators that support truecolors: What to do upon encountering \e[38;6;1;2;3;4;5;6;7;8;9m? I don't know, since I don't know what "38;6" will mean at some point in the future.

This can be fixed by having colon as the separator. Receive a \e[38:2:3:4:5;7m and even if the emulator has no clue what "38:2" means and drops it, it can drop it along with the colon-separated parameters, and still interpret the 7 after the semicolon.

Similarly, if an emulator sees a \e[38:6:1:2:3:4:5:6;7;8;9m, it can drop that mysterious future "38:6:1:2:3:4:5:6" that it doesn't know about, and still enable modes 7, 8 and 9.

In order for this to work, emulators strictly MUST NOT treat colons as aliases to semicolons, in that case there would be absolutely no point in introducing another character for the very same purpose. They must implement this two-level parsing with semicolon being the "major" separator and colon being the "minor" one, and must reject the colon in the "major" separator position. E.g. \e[38:2:10:20:30:48:2:40:50:60m must not switch the background to rgb(40,50,60) (and probably shouldn't change the foreground to rgb(10,20,30) either). Sadly, for compatibility reasons, they should also parse if these params are separated by semicolons (of course then it's not possible to drop unknown sequences) and even ones where the first separator is semicolon and the rest are colons, as discussed in KDE #107487.

For VTE this it was implemented in GNOME #685759. As I've tried xterm it also seems to correctly reject if colon is used somwhere else other than between multiple parameters for a color. As far as I can see, these are all the emulators on Linux that support colons. I have no infrastructure to test the behavior of emulators running on Win or Mac, although I would love to see if they support colons properly in this regard.

@egmontkob

The a in setaf/setab is for "ANSI".

Tc is a flag that says "this terminal supports the ISO RGB colour sequences." Yes, we could check for the presence of set24f/set24b/setf24/setb24/whatever instead if people are using them. There is precedent for flags that mean a hardcoded sequence is supported (such as AX and XT), but I agree that strings giving the actual escape sequences to send would be better.

I really don't have any particular attachment to it being a flag, I was just pointing out what tmux currently does :-).

The colon form might seem sensible but it isn't useful in practice and I doubt it will ever be. But in any case, we agree that terminfo should use semicolons, other than that it doesn't matter.

I could support set24f and set24b in tmux, in the form you suggest in the GNOME bug, but without terminfo support users would still have to add them themselves. I'm a bit reluctant to add any code unless there is some indication other people are going to use it too though.

So do we have opinions from other application developers on whether they would support it? I guess vim, emacs and slang are probably the big ones from the list that currently support RGB colour.

Of course the most future proof solution would be for terminals to be self-documenting and able to tell applications their own capabilities. You can get some (fairly useless) flags and stuff with DA/DA2, and xterm does have some experimental support for retrieving terminfo entries with DCS+q but unfortunately it only supports keys. A way to say "give me your whole terminfo entry" would be much better. We would still need tparm() or equivalent to expand the parameters and whatnot, but it would avoid some of the problems of a central database. Perhaps terminfo is too entrenched anyway. And this is not really on the topic in any case.

@nicm Could you please clarify: are you a tmux and openbsd developer? :)

The two of us are pretty much on the same page, that's good (hoping we can convince others). I hope slang and emacs developers will be easy to convince. Not sure about vim, I feel it often tends to prefer its own solution (e.g. its own config file option), I'd delay that for a while.

It would be quite important to get buy-in from a few key distributions that would patch their ncurses, IMO at least Debian and Fedora.

I guess the next step is to find the proper way of coming up with a suggestion and pushing this towards people. I mean the comment thread here is far from ideal, at least there should be a dedicated page for this. What do you think would be the right way to go ahead?

Re Tc vs set24f: setaf/setab have a tiny bit of ambiguity: for the first 16 colors it's not obvious whether to use the legacy or the 256-color escape sequences. At least xterm's entry seems to encode an if-branch for 0-7, 8-15, 16-255 intervals, mapping the first 8+8 to the 30..37/40..47 and 90..97/100..107 range. This might be a reason for having a terminfo entry. RGB doesn't have this kind of question (apart from the colon/semicolon issue). So this might be a tiny reason for going with Tc. However, I believe the nicest is if we copy the pattern of setaf/setab as much as possible, so I still tend to vote for set24f/set24b (or whatever name will be chosen) rather than Tc.

As for the name, somewhere (can't remember where) I saw that either "38;3" or "38;4" (can't remember which) should be similar to "38;2" but work with hue/sat/val. I guess that one also takes 3 8-bit parameters. (I don't think any emulator does or will ever implement this, and if still, it'll probably immediately convert to RGB.) As such, I'm wondering whether maybe setrgbf/setrgbb might be a better name than set24f/set24b.

Re your latest post: I agree with you, something like the $TERMCAP environment variable fully describing the behavior and getting forwarded via ssh might be a good solution. As you also said it's way beyond the scope of our current discussion, and I won't have capacity to work on anything like this.

@egmontkob Yes I am tmux and OpenBSD developer, and I maintain the terminfo database for OpenBSD.

I'm happy with terminfo entries called either setrgbf/setrgbb or set24f/set24b or setf24/setb24, it doesn't matter much to me. I think using three arguments is more important.

I think someone who is interested and has an appreciation of the issue needs to talk to some of the application developers. Since emacs have already defined capabilities, perhaps it would be best to first ask them why they chose to use one parameter and if they would consider changing before it gets into much use (or makes it into a release or whatnot). I don't think the name is of huge importance, or their choice of having entries for both colon and semicolon (I expect the colon one will just die off in time). But the use of one argument instead of three is a big question mark and I think it will make it harder to both get application developers to adopt it as well as reducing any hope of getting it into terminfo upstream. If they do change, then it is just a matter of people adding support (it will be a simple change for tmux and probably for most other programs too), which will probably happen over time so long as developers are aware other programs are using these capabilities.

Saying that, I don't particularly want to volunteer to do this :-).

Didn't you do basically the same as this for SGR mouse? ISTR you opened issues for a load of programs which definitely helped to drive it forward.

There must be a reason they chose to use one argument. Perhaps they just used emacs' internal form of RGB colour, or they didn't know that terminfo can support multiple parameters (which seems unlikely). Anyway, terminfo entries can have up to nine parameters.

In fact, there is already a sequence that accepts RGB colours, but for a different purpose -- initc, which has four arguments:

       initialize_color              initc      Ic        initialize color #1
                                                          to (#2,#3,#4)

initc accepts R,G,B scaled out of 1000:

$ tput initc 1 500 500 500|cat -v
^[]4;1;rgb:7F/7F/7F^[\

So there is an argument that a new sequence should use 1000 too. I'm not sure we should necessarily get into that though, I think 255 would be both simpler and better.

This comment in their commit message at http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e463e57 does imply they would be willing to change if something better comes along, perhaps we could drop an email to the committer?

+Currently there's no standard way to determine whether a terminal
+supports direct color mode. If such standard arises later on, support
+for @samp{setb24} and @samp{setf24} may be removed.

@egmontkob - I've imported that gist into the repo and gave you access. If you can think a better name for a repo and organization - please write your suggestions. I think with all latest developments and suggestions this needs to be a repo to have an issues and pull requests, as like as more than one contributor.

you can use my scripts to test. I gathered a few of these color-printing scripts in one.

https://github.com/pvinis/colortools

or you can install with brew install pvinis/pvinis/colortools

Please add:

DomTerm-based terminals (qtdomterm, ldomterm) [delimeter: colon, semicolon]

@nicm I'm sorry but I've totally lost motivation in this one (at least for now) and moved on to working on another hopefully cool idea. I might get back to the truecolor vs terminfo story later (in several months/years) but I cannot promise. I hope others will solve it by then :)

I see no link to the repo @XVilka referred to in #gistcomment-2010783 but I assume he meant https://github.com/XVilka/term-color

@XVilka May be you should add a link to that repo in this gist?

Terminix has been renamed to Tilix btw due to some legal issues

@egmontkob fair enough, I don't use it so there is a limit to how much time I want to spend on it myself

Kinda offtopic, but this one got me:

Of course the most future proof solution would be for terminals to be self-documenting and able to tell applications their own capabilities.

This idea is really intriguing. Yet it boils down to the same old problem - you need some "authority" that clarifies the semantics for the players, emulators on one side and program (libs) on the other. Thats kinda what terminfo does atm in a very compact and static way (that might be discussable with all pros and cons). Also note that XML kinda failed for that reason, it just introduced more and more technical sub-sub-specifications while missing the ease of use and ppls needs, and ppl started to use technically simpler solutions like JSON. In the end its all about semantics ;)
Maybe use more of the self reporting functions? Idk, maybe some kind of a "handshake protocol" can help, it still needs the authority...

Edit: And to open pandora's box - this also touches very fundamental POSIX things - what is a terminal, what should it be like in the future? What about backward compatibility? Are we stuck to VT100 with some color enhancements forever? :O Just to name a few...

Isn't it time for termcap to start supporting it?

Regarding mlterm: First, ttdoda's comment is absolutely right, it is not based on VTE. Second, as discussed here, it has an internal palette and easily runs out of available indices, in which case colors become corrupted. As such, I'd argue that it does not properly support true colors.

<spam>
Not related to truecolors, but I thought you guys might like this. This is what I was working on recently: Hyperlinks (a.k.a. HTML-like anchors) in terminal emulators.
</spam>

@egmontkob fixed, thanks.

@jerch - the structure of terminfo is fine, and having a central authority for the meaning of terminfo capabilities is not the issue. All we need is a way for terminals to report some or all of the terminfo entry themselves and a way for programs to deliver that to libtinfo etc. Then terminal authors can maintain it for their terminal, it can match the terminal's current version, etc, instead of requiring a central repository which is very slow to roll out.

Perhaps add mosh and their discussion on truecolor? mobile-shell/mosh#649

Why is it hard to true-color-ize xterm-based terminal?

@egmontkob and @nicm, in neovim/neovim#6816 I have already (0fab6e275fe2e7ce357614ab1a7a5f535ba60502) changed nvim to share the Ss and Se terminfo extensions pioneered by tmux. I intend to treat RGB support the same way. For the capabilities, I plan to go with Rüdiger Sonderfeld's proposal from 2013. It is sensible, and uses 3 parameters.

The way that nvim handles Ss and Se capabilities will also be the way that it handles setrgbf and setrgbb. If the capability is present, it will be used as-is with no further modification. terminfo is authoritative if present. If it is absent, nvim will determine when to fix up the terminfo record, based upon a rough parsing of terminal types; just as it does for Ss and Se (q.v.).

@jdebp from the next release (2.6), tmux will look for setrgbf and setrgbb capabilities for RGB colour. If they are not present, it will fill them in itself if the Tc flag is present (so the current behaviour).

@jdebp if you do something different, let me know please and I will change tmux, it will be OK to change it until the next release (in Sep or Oct).

@XVilka: As @fornwall mentioned, Termux (open-source Android terminal app w/ ssh client) does have true-color support. JuiceSSH and Termius (closed-source Android ssh client apps) do not. ConnectBot (open-source Android ssh client app) does not, but I just sent a PR to add it connectbot/connectbot#531.

@XVilka: On the link for img.sh, can you just remove the "?h=vte-0-36". The latest version of img.sh fixed an issue I experienced with the vte-0-36 version.

@whydoubt, @dennisse - added mentioned entries and fixed the link. Thanks!

Hi all. I'm having some truecolor trouble on Alacritty, gnome-terminal (tested both with and without Tmux).

I'm using a program that outputs png images in truecolor to the terminal: https://github.com/nabijaczleweli/termimage

After displaying the image, my output gets blocked/blacked out somehow. This is the result of me pressing enter a few times, then pressing ls twice:
screenshot

You can see the command prompt is hidden, and most of the first ls output is truncated. After that, it's fine.

Anybody know what could be causing this behavior? This only occurs on my computer, I asked some people to test it on their computer and they had no issues.

I'm using Fedora 25, i3wm, lightdm, alacritty/gnome-terminal both tested, tmux and without tmux both tested.

edit 1
Here's a friend's output: https://i.imgur.com/QMtrGf8l.png

As you can see his prompt resumes immediately after the program exits (as expected).

edit 2

So when ls prints a color character on my terminal, that's when things return to normal. This led me to the solution, if I print \033[0m after the image displays, everything is OK. Now I'm curious why I need to explicitly print this character.

@sevagh Apparently termimage is broken in the sense that when it exits, it leaves the foreground color at an explicit black rather than the default foreground of the terminal emulator. Hence it's black until someone (shell prompt or ls or anything else) changes it. termimage should restore the terminal's default foreground and background color when it quits.

Update: I see you filed this bug against termimage and they've already fixed it.

@XVilka Can you add Eternal Terminal to the list of products that support true color? https://mistertea.github.io/EternalTCP/

@MisterTea @sevagh - thank you, added.

Windows 10 bash console

Do you have any source that says it is restricted to the bash console? All terminals on Windows (PowerShell, CMD, WSL Bash) run in the Windows Console Host. I am pretty sure that they added the colour support to the Console Host, which means it's available to all terminals, not just "bash" (I assume you mean WSL Bash, you can also run a MinGW bash on Windows that is bundled with git)

I made a command line image viewer with 24-bit support a while back, don't know if you want to add that as well? https://github.com/Tenzer/explosion

Hi, I forked ls to make it with icons that support true colors: https://github.com/sebastiencs/ls-icons

Adding entries to the terminfo database shouldn't require that the ancient and backwards ncurses "color pair" rendering engine be able to use the feature. IMO, terminfo needs a divorce from ncurses because the ncurses maintainer is getting hurt feelings and retarding progress for absolutely no good reason at all.

In fact, no reason is given at all for not wanting to have a standard 24bit color entry except essentially stating that ncurses indexed rendering method sucks too much for it to use 24bit color. The only real reason I can detect is the unsubstantiated claim that people were "harassing" Dickie -- So PERHAPS he has set out to punish everyone for his hurt feelings by ignoring the most widely used terminal emulators support 24bit color -- Note: it doesn't matter if many use vte or not -- what should matter is the number of users affected by the lack of supporting a standardized 24bit color mode. This should be trivial to add to terminfo, and people actually patch their terminfo databases to add the color support for emacs.

Entries existing in the terminfo database should not be predicated on whether ncurses rendering API can use them or not (the terminfo API is fully capable). There are many existing entries in terminfo which ncurses does not use. We all shouldn't have to suffer just because ncurses duplicated the bad design of curses "color pairs" which results in O(n^2) complexity (vs saner methods of compositing individual FG / BG attributes on the fly, i.e., O(n) attribute complexity). In fact, the very purpose of an API that insulates users from the internal representation or display protocol should be to allow migration to better internal code without breaking applications.

Here is a hack using only escape codes to print 24bit rainbow color on Linux "kernel" terminal The ones on [Ctrl+Alt+F1 to F7]. It will work if your kernel terminal is emulating 16 colors atop a frame buffer that actually supports 24bit color (this is the case on most desktop systems since Linux kernel integrated a framebuffer years ago [back on 2.6.something] ).

An application using this method to display 24bit color just has to keep the display from scrolling since the linux terminal will redraw the screen using its current 16 color palette. This is very hacky but demonstrates that even the lowly Linux terminal COULD easily be made to support 24bit color (just track which colors go where, and Bob's your uncle). Perhaps skilled programmers would submit patches to upgrade the projects if maintainers weren't so crusty, arrogant and dismissive of new features they don't personally desire.

TL;DR: A maintainer of terminfo who is not inept or wilfully ignorant should be jumping at the chance to get out ahead of a feature and get it standardized before it becomes a myriad of incompatible formats. Unfortunately ncurses is apparently not maintained by someone who fits this description. Since Dickie is against adopting standardization of new widely available features it seems he does not want to maintain the ncurses / terminfo project(s). He should just resign if that's the case.

kind regards,
random demoscener

p.s. I would like to add that "TRUECOLOR" is a registered trademark of Microsoft and therefore is a string that should / would be avoided by any knowledgeable FLOSS developer on this planet.

@Tenzer @sebastiencs - thanks, added them in list.

Since I can't edit Wikipedia from China or through VPN, can someone please update the corresponding Wikipedia article https://en.wikipedia.org/wiki/ANSI_escape_code to reflect the actual support rate of the 24bit RGB colours among terminal emulators and console programs? Thank you.

hterm has true color support.

@joshklod thanks, added.

It would be great if this gist mentioned the fact that rxvt-unicode can display correct colors as long as there are not too many similar colors simultaneously present on one screen. This is because it automatically adjusts its palette. Not knowing this made me waste several hours looking for alternative terminals while rxvt-unicode actually worked perfectly fine for my purpose...

@takano-akio I cat'ed my usual test file of truecolors in Ubuntu Zesty's rxvt-unicode 9.22, and none of the colors were even remotely close to the expected value. So this must be a newer feature, a third party patch, or behind a config option. It would be nice if you could please track down the details.

@egmontkob As the gist mentions, this feature was introduced in http://lists.schmorp.de/pipermail/rxvt-unicode/2016q2/002261.html, and is not in any release yet (as far as I know). I had to compile the version from svn to use this feature.

Hi, I updated the putty patch to support true color. I removed some of the nasty format changes and it does apply to current PuTTY HEAD. Patch available in my putty fork (truecolor branch).

@chrisbra thank you! Added in the gist, we need to ping PuTTY maintainer to include those, I haven't found any way. I wrote the suggestion via the site, but no answer since this.

@XVilka, would love to see this merged, since Putty is my favorite terminal emulator on Windows. I just pinged back the Putty devs.

JOE supports 24-bit color via the COLORTERM environment variable as of 4.5, released today.

the link to mtputty does not work

The putty patch has just been merged. There is no release yet, but starting from tomorrow the nightly builds should support true color and I guess the next release 0.71 will also contain this feature, whenever it will be released.

Thanks to everyone, updated the gist, added also Micro Editor

@chrisbra: I worked on some updated PuTTY patches (https://github.com/whydoubt/PuTTY/commits/true-color-rdb) and sent them to the developers back in June (I thought I had mentioned it here, but apparently not). It seemed to go down a black hole. While I am disappointed in that, I am glad your work made it in. I will have to check it out.

Mosh support is being worked on at mobile-shell/mosh#939.

S-Lang author added a check for $COLORTERM containing either "truecolor" or "24bit" (case sensitive). … This is obviously not a reliable method, and is not forwarded via sudo, ssh etc. However, whenever it errs, it errs on the safe side: does not advertise support whereas it's actually supported.

It’s not that safe, because terminals launched from other terminals inherit environment variables. If the outer terminal sets COLORTERM=truecolor and the inner terminal doesn’t support it, applications running in the inner terminal will think it’s supported when it isn’t. This is an issue in practice with common combinations like screen inside gnome-terminal.

@andersk: well, there is no other way, since terminfo maintainer basically declined to add this feature in it. The only clean way might be only a fork of terminfo, but I'm already busy with radare2, do not have time to maintain the fork.

Yeah, I recognize we don’t really have a better solution at this time, but we shouldn’t be pretending that the current one is better than it is. Perhaps it could be mostly repaired if we could somehow get all terminals to agree to unset COLORTERM if they aren’t setting it, but until we get there, the “errs on the safe side” claim should be removed.

if we could somehow get all terminals to agree to unset COLORTERM

@andersk The maintainer of xterm and ncurses+terminfo has multiple times pragmatically refused to implement true color support in xterm or ncurses, and even to add a truecolor parameter to terminfo. I don't see too much chance he'd be willing to unset an env var that is a terrible workaround against something that he himself prevents from being solved properly.

I think weston-terminal does not support true color.

According to this thread, 24-bit color depth is now implemented in mosh ;)
EDIT: Oops, It seems that you already added to the gist, sorry.

Up to today VTE contained a significant memory leak if the colon form was used (1, 2, 3). Embarrassing.

You might want to add a link to "tcell" github.com/gdamore/tcell -- this is the underlying library that micro and other Golang programs use to access 24-bit color. (In contrast, termbox does not have this capability.)

@egmontkob https://git.gnome.org/browse/vte/commit/?id=dda73cc fixed for now

So there's a problem here...

@rdebath mentioned it exactly two years ago, but no one seems to have paid attention, and we kept propagating/implementing incorrect syntax.

According to ITU-T Recommendation T.416, also known as ISO/IEC 8613-6, the syntax for RGB true color is

\e[38:2:[color_space_id]:red:green:blue[:unused:tolerance:color_space_for_tolerance]m

It's not only that the current widespread use of semicolon as separator is not mentioned at all in this specification, there's also an off-by-one as the color space identifier parameter is forgotten. Let alone that by its nature, the semicolon format cannot take additional optional parameters (after consuming the red, green and blue parameters, the remaining ones, if any, are brand new SGR codes).

At this point I would recommend that terminal emulators supporting true colors accept at least two formats: the one in current widespread use, that is,

\e[38;2;red;green;bluem

and the correct one according to the specs, as shown above. To give concrete examples, these two should be equivalent:

echo -e '\e[38;2;170;187;204mThis is #AABBCC\e[m'
echo -e '\e[38:2::170:187:204mThis is #AABBCC\e[m'

That is, the parameters are shifted by one depending on the separator character being used. Plus, the colon-separated form should allow the presence of further additional parameters.

For compatibility with those who emit colon as separator, but forget the color_space_id attribute, a terminal emulator may also accept the colon format with exactly 3 parameters after "38:2:" and interpret them as red, green and blue (skipping color_space_id). I have no firm opinion whether terminal emulators should accept this format or not. It's probably not in widespread use (everybody seems to use semicolons), so refusing such sequences probably wouldn't break too many things out there, but probably still would break a few ones (such as users' custom prompt colors).

Whereas correcting the parameter positions can be done pretty much painlessly for the colon format, it couldn't be done for the semicolon format without seriously breaking existing RGB support at plenty of places. For example, two concatenated color codes, such as \e[38;2;170;187;204;48;2;221;238;255m for #AABBCC text on #DDEEFF background emitted by existing apps would be parsed as color_space_id of 170, foreground color becoming #BBCC30 and then whatever happens to the remaining parameters. It's not even clear how additional optional parameters could be parsed, this would conflict with the general possibility of appending multiple SGR codes in the same escape sequence. (Yet another data point for the colon format being superior to semicolon.)

Bugreports: VTE, iTerm2, Kitty, Konsole, screen, chromium-hterm, more to come...

@egmontkob, I mentioned it, and it appears obvious that the first implementation made a mistake.
BUT that DOES NOT MATTER.

As far as I know this page of T.416 has never been used. If you ignore the scrollback you only need (maybe) a dozen colour pairs before the screen starts to look messy. So even when displays became cheap it wasn't considered necessary; you could define a palette.

This means there are no preexisting implementations to be compatible with or to show how it should be done. So you should make your implementation compatible with the first guy on the line.

Secondly, I think you've got it wrong too. T.416 talks about "parameter substrings" which are made of "parameter elements" and directly says that the 38 or 48 is not the "first parameter element" of the "parameter substring" which would make this the valid string: \e[38;2::170:187:204;48;2::221:238:255m and \e[38;3:132:17;48;5:252m assuming the number ranges are anything like the values the original authors had in mind.

And lastly, the including of colons may have been a good idea at the time but NOTHING has ever gone anywhere with it and it's really, really unlikely that they will be used for anything else. After all the "mis-use" of semicolons also applies to "256 colour mode" colours, apparently all caused by the exorbitant pricing of the T.416 "standards document".

So MY recommendation would be that the default is as it is right now with semicolons, no colourspace and fixed length prefix codes. Then just for CSI m (sgr) the : is an exact substitution for the ;. In the unlikely event that any emulator needs to be precise with the colours or extend the colour gamut they use the extension abilities built into ECMA48 and define their own private sequence with exactly the semantics they need. Not trying to re-use an old educated guess of what the future might want.

SecureCRT supports TrueColor from version 8.7

xterm v331 supports TrueColor without palette approximation, called in "Direct Color" in its source
see https://github.com/ThomasDickey/xterm-snapshots/blob/master/charproc.c#L1822

ncurses' terminfo doesn't reflect it (yet) - no Tc flag

@egmontkob xterm supports semicolon seperated parameters or colon seperated parameters. It supports optional parameters - including the colorspace - whose values are currently ignored. See the comments here: https://github.com/ThomasDickey/xterm-snapshots/blob/master/charproc.c#L1729

The following sequences are accepted by xterm v331

CSI 38 ; 2 ; R ; G ; B m
CSI 38 ; 2 ; R : G : B m
CSI 38 ; 2 : R : G : B m
CSI 38 ; 2 : Colorspace : R : G : B m

I also made a small script to test theses sequences (based on pymux's script) and they all work in xterm v331 https://gist.github.com/piec/56a9f3eba5374db589801e213da6645e

Also I've contacted Thomas Dickey to suggest adding "Tc" to xterm and other terminals that support "True Color" and he says he has plans to address the subject. So let's wait and see what happens in terminfo

Latest Terminfo supports 24-bit terminals: http://lists.gnu.org/archive/html/bug-ncurses/2018-01/msg00045.html. There is an "RGB" flag that indicates true color support. The "setaf" and "setab" strings accept 24-bit pixels as arguments.

I posted a patch to support this method in Emacs: https://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00679.html.

@piec @rylimaki thank you! Added in the gist.

Mr. Dickey accepted my patches, so now xterm can do True Color. It looks like it will be configured by default in xterm 331.

Ncurses supports truecolor!!! https://www.gnu.org/software/ncurses/

BTW, Vim and Neovim both can now go into “terminal multiprexors” category (though it is a bit off: :terminal in both cases has other uses). Both use libvterm (though Vim has its own fork) and support true color coming from apps run inside terminals (if I am not mistaking, RGB approximation in case set notermguicolors). Pangoterm mentioned somewhere above also uses libvterm, but is not in a list.

How about making this page wiki page somewhere? Wikipedia page is too brief on the matter.

@ZyX-I Thanks, added pangoterm. Speaking about moving into some wiki - sure, but what are your suggestions?

@XVilka I would go with GH one. For non-project-attached pages first variant is creating wiki attached to your github.io “website”, though for me this is fine only because I do not actually use it, but do have it.

According to it's readme, kitty supports true-color now as well.

Looking at ncurses-6.1's definition of xterm+direct, it goes like

    setaf=\E[%?%p1%{8}%<%t3%p1%d%e38\:2\:\:%p1%{65536}%/%d\:%p1
          %{256}%/%{255}%&%d\:%p1%{255}%&%d%;m,

As much as I can read this syntax with my naked eyes, as well as double-checked with commands like TERM=xterm-direct tput setaf 7 | cat -v, this means the following.

A simple parameter is taken. If it's from 0 to 7 then convert to \e[30m .. \e[37m (40..47 for background) for the old-fashioned 8 colors. If it's greater than or equal to 8 then it's converted to \e[38:2::R:G:Bm according to mod/div 256 arithmetics.

So:

It's not an extension on top of 256 colors, not even on top of the well-established 16 (aixterm?) colors, even indices 8-15 (escape codes \e[90m to \e[97m, or 100..107 for background) aren't available anymore. Only the 8 legacy palette colors remain, plus truecolors.

Moreover, should an app try to have a color from #000000 to #000007, it'll get the palette colors instead.

Does anyone think it's even remotely useful??? Seriously.

@egmontkob, oh, thanks for the heads up! Right, this looks like a VERY strange implementation then.

So how would you implement true colors with ncurses?

At this point we're not yet talking about true color support in ncurses (the screen drawing library), only a description of the terminal emulator's feature in the terminfo database.

There have already been several proposals, e.g. new capabilities called set[fb]24 or set24[fb] or similar (perhaps taking 3 parameters, rather than R, G and B squeezed into one); or a new Tc boolean capability just to describe that support is available without saying what the escape sequences are. If the existing seta[fb] need to be piggybacked then the truecolor parameter could be offset by 256 (to leave room for the compatibility 256-color palette), or by 2^24 (high bit set) or whatever.

There are plenty of ways to do this that (1) don't break backwards compatibility, (2) handle colors #000000 .. #000007 correctly, and (3) don't make users have to choose whether 256-color-aware apps can use 256 colors exclusive or true-color-aware apps can use true colors. The current approach doesn't satisfy any of these.

The Token2Shell, a Windows UWP app, supports true color. Please add it.

FYI this fork/branch of rxvt-unicode works well with truecolors: https://github.com/da-x/rxvt-unicode/tree/v9.22-with-24bit-color

Mudlet (telnet client) supports truecolour with 3.8: https://www.mudlet.org/2018/04/mudlet-3-8-0-more-improvements-for-internationalization-and-multiplaying/

\e[38:2:[color_space_id]:red:green:blue[:unused:tolerance:color_space_for_tolerance]m

@egmontkob
Since the spec forgot the A in RGBA (the alpha channel must have been invented after 1993 😉), lets claim the "unused" for transparency. RGBA ftw 😄

the alpha channel must have been invented after 1993

Nope, according to Wikipedia it dates back to late 70's / '84. I guess it's more like that these specs are about physical terminals as well as emulators that emulate physical terminals, and those cannot do transparency.

I'm not against extending the spec this way, but I have absolutely no intent whatsoever to implement this in any emulator or library or terminal-based application. Unlike true color support itself, I cannot see this feature serving real user needs. (Note that many people don't see this in true color support either.)

One thing to specify: Does a translucent foreground color mean that (1) the cell's background color peeks through, that is, you imagine that the cell is fully painted using its background color, and then the letter is painted using the foreground color; or (2) whatever is behind the window peeks through, that is, the background color is only painted wherever the foreground is not painted? It seems to me that (2) allows more freedom to apps, so my vote goes for (2).

Unlike true color support itself, I cannot see this feature serving real user needs.

I hear you and to be honest, for me even the RGB colorspace thing is questionable, it will hardly be used with more than a handful colors in one session. Still people want it, i think it is more about the ability to control finegrained color output than the sheer amount of colors. And since there is even a CMYK specification with the 4th parameter used for black it seems reasonable imho to use that slot for transparency if RGBA is supported.

About the "What does a translucent foreground color mean?" problem:
(2) sounds much more versatile and even might avoid opacity stacking problems, (1) seems to be more logical from the "foreground stuff is rendered onto a background" perspective, though this directly leads to typical layer composition questions, which isn't specified anywhere. I guess (2) would be the way to go, still this might be not doable for some output systems.

Last but not least, I'd propose this value to be an uint8_t integer type (digits from 0..255) as opacity with a default of 0. Integer instead of a float for better compatibility with existing parsers and memory savings (though this would lock the alpha blending caps to 255 steps).

I'd propose this value to be an uint8_t integer type (digits from 0..255) as opacity [...]

Obviously. Although not stated anywhere in the standards, in practice the R, G and B channels take values from the 0..255 range. It would be silly to have a different range for A.

[...] with a default of 0

Nope, for compatibility with those who omit this number, the default must be full opacity, that is, 255.

Nope, for compatibility with those who omit this number, the default must be full opacity, that is, 255.

Which is incompatible with the DEC standard, which assumes omitted parameter either being 0 or 1, therefore the proposal 0 being fully opaque and 255 fully transparent (sorry "opacity" was misleading, better call it transparency, since it works opposite).

Which is incompatible with the DEC standard

Reference, please! Are you sure the DEC standard specifies this for the colon-separated parameter element, and not the semicolon-separated parameter?

I'm looking at ITU-T Rec. T.416 which defines colon-separated parameter element on page 41, and then says "An empty parameter element represents a default value for this parameter element" without limiting it to 0 or 1.

I cast a big fat "NO" vote for using the opposite of alpha (swapping the two ends of the scale).

Visual Studio Code sort of supports true colors, but imperfectly.

This image is supposed to have an x axis of green and a y axis of red, going from 0 to 255 in increments of 5. As evident there are some colors that don't work perfectly.

@egmontkob
Problem behind is the zero default mode, which was part of the first ECMA spec of 1976 and later removed (see ECMA-48 Annex F4.2). According to vt100.net a VT500 compatible would have to assume a missing numerical parameter to be equal to the meaning of 0:

... a VT500 parser needs to treat both empty and zero parameters as representing the default ...

On the other hand DEC had no own use case for subparameters separated by colons, all machines would silently swallow the escape sequence (same with all other possible chars =><?). Therefore a VTxx compliant emulator cant use the colon notation without additional non conformant parsing (which is the case for true color anyways).

Taking this into account it seems reasonable to me to invert the standard alpha channel meaning - it covers the above as well as possible. Conversion in C would be not that hard, but well yeah, people might wonder wth...

For completeness:
The parsing rule above allows another interpretation (similar to the handling of 0|1 of cursor positioning): Set the default to 255 than 0 would also stand for 255. What about the rest of the scale? Normal alpha values? Is 1 now the alpha 0? Mapping nightmare and even one value short ....

and later removed (see ECMA-48 Annex F4.2)

So, why insist on conforming something that has no longer been a standard for the last 27 or so years??

According to vt100.net

Can you please point me to a specific sentence on a specific page?

Also, note the difference: you say "would have to assume a missing numerical parameter to be equal to the meaning of 0", whereas colon-separated numbers are parameter elements, and that's not the same.

On the other hand DEC had no own use case for subparameters separated by colons

And it seems to me that ECMA-48 doesn't even define the concept of subparameters (a.k.a. parameter elements), this is added by T-416. And T-416 doesn't say anything about the possible default value either.

Taking this into account it seems reasonable to me to invert the standard alpha channel meaning - it covers the above as well as possible. Conversion in C would be not that hard

It's still absolutely unreasonable for me. It's not that it's hard to implement, but it's still unnecessary complexity, unnecessary pain for developers (pretty much every developer would go through the cycle of: doesn't work, let's debug, oh cr@p, who the f came up with this, let's fix), and most importantly, it's that people will forget it, and you'll end up with software that do it the other way around. Upside-down value is something you just don't do. Don't. Especially for the sake of a sentence in a standard that was removed 27 years ago, let alone didn't even apply to this very context back then.

If there's a reason we cannot default to 255 (which I cannot see at all), the solution would be to introduce another leading value (like it's 2 for 256-color mode, 5 for RGB, maybe 15 for RGBA) with mandatory alpha value. (And while at it, we might be thinking about 15 taking floats, or 16-bit values as parameters.)

[Edit: 1991 was 27 years ago, not 17, LOL]

Can you please point me to a specific sentence on a specific page?

It is stated on the emulation page https://vt100.net/emu/dec_ansi_parser under param.

Also, note the difference: you say "would have to assume a missing numerical parameter to be equal to the meaning of 0", whereas colon-separated numbers are parameter elements, and that's not the same. [...] And it seems to me that ECMA-48 doesn't even define the concept of subparameters (a.k.a. parameter elements), this is added by T-416. And T-416 doesn't say anything about the possible default value either.

Yup, all true. ECMA-48 and X3.64 left those blank with a note for later further specification. Also it seems DEC never used those anywhere (even not in private sequences) and would instead drop any sequence containing a colon in the parameter section. This might be the reason for the semicolon true color style we face today, the first implementer (xterm?) might had DEC compatibility in mind back those days (real VTs where still in use):
If you have a closer look at the state diagram on the emulation page, you can see, that once the "csi ignore" state is reached, there is no way back. This means as soon as a colon appears any following stacked CSI rule would be dropped as well. DEC compliant? - No sub parameters, colons etc. at all.

Why I am iterating over the old DEC stuff at all? Well almost every emulator used to state some degree of VTxx compliance. Most of the time this was much more important than some not accessible spec rules. To me this boils down to the more fundamental question - drop finally the DEC thingy and move on or keep it compatible as close as possible? Im not a big fan of those old inherited stuff either, still I feel the need to choose the path carefully. How should a modern terminal application render on an old Vtxx? Correctly, acceptable, not at all? Regarding the problem at hand - since DEC never used those sequences itself in its products, the ZDM thing cant easily be applied to parameter elements, right. It is more about existing emulators, how close they reassemble VT compatibility and how easy their "hot parsing loops" can be extended by custom functionality. As for the parser described on vt100.net this introduces alot of additional state handling, for example.

About your developer concerns - Imho thats not a problem at all if documented clearly:
\e[38:2:[color_space_id]:red:green:blue[:inverted_alpha:tolerance:color_space_for_tolerance]m
Thats not hard to grasp imho.

About your developer concerns - Imho thats not a problem at all if documented clearly:
\e[38:2:[color_space_id]:red:green:blue[:inverted_alpha:tolerance:color_space_for_tolerance]m
Thats not hard to grasp imho.

N years of software development experience still tells me that inverted_alpha is a no-go. People are going to get it wrong, causing too much trouble. I keep my firmest "NO" vote on this.

At this point I don't believe anyone is attempting to make it a (somewhat) standard or to implement this feature, and as such, I don't see any point in continuing this stalled debate. Anyone interested has heard two opinions, and this debate should be revived (further input sought etc.) whenever someone actually implements this.

Agreed, guess we got carried away about a tiny detail in the end.

I can't find any discussion here, or on the net in general about true colour support in the non-gui Linux console, the console you get before logging into a GUI. I think it's generally run by agetty? And from what I can see it doesn't support true colour?

the non-gui Linux console [...] I think it's generally run by agetty?

The other way around. The console (usually 6 or so of them – or maybe it's one console but multiple VTs, I'm not entirely sure what the correct terminology is) exist first, and then later some getty is run on them which displays /etc/issue, asks for login name, invokes /bin/login to authenticate the user, which then launches the user's shell.

And from what I can see it doesn't support true colour?

The console can either use the video card's VGA (text) mode, or framebuffer. In case of VGA mode, only 8/16 colors are available. For framebuffer I think it would be possible to have true color support, but I truly doubt it's implemented in the kernel. In fact, probably 256 color support isn't implemented in the kernel's framebuffer mode either.

There is, however, a standalone application called fbterm which implements a terminal emulator for the framebuffer in user space. Allegedly it supports 256 colors. Its development stalled in 2010, so it almost certainly doesn't support true colors, although I guess theoretically it could.

My 2 cents: The Linux console shouldn't be used for anything other than repairing severely damaged systems, in which case having only 8 or 16 colors should be the least of your worries. For everything else there's the graphical system with its significantly more feature rich terminal emulators, plus the ability to run other apps (e.g. a graphical web browser) as well. Or, in case of servers without a graphical system, there's ssh from a desktop computer.

As of version 2.0, Hyper.app no longer supports true color (vercel/hyper#2294) as it is based on xterm.js, which lost truecolor support some time ago. (xtermjs/xterm.js#484)

Updated.

[11/8/18 12:16:53] <bes_internal> does truecolor works in gnu screen version 4.6.1?
[11/8/18 14:16:51] bes_internal: does not look like support for truecolor is in the v4 branch
[11/8/18 14:17:33] http://git.savannah.gnu.org/cgit/screen.git/commit/?h=screen-v4&id=c91ab9

One does not accidentally add a section to the manpage :) Truecolor is allegedly available in screen's master (future 5.0) branch, just not in 4.6.

I'm a co-coder on Mudlet with @vadi2, responsible for it's current interpretation of direct RGB colour SGR codes and I would concur with @egmontkob about needing to handle ':' when supporting 16M-colour mode - because without using it it is not possible to omit trailing Pes without leaving glaring ambiguities for the decoder to try and guess to handle the codes. Referring to the source - available in the official ITU free pdf form in English, French and Spanish from: https://www.itu.int/rec/T-REC-T.416-199303-I the page labelled 41 there includes:

The parameter values 38 and 48 are followed by a parameter substring used to select either the character foreground “colour value” or the character background “colour value”.

A parameter substring for values 38 or 48 may be divided by one or more separators (03/10) into parameter elements, denoted as Pe. The format of such a parameter sub-string is indicated as:

   Pe : P ...

Each parameter element consists of zero, one or more bit combinations from 03/00 to 03/09, representing the digits 0 to 9. An empty parameter element represents a default value for this parameter element. Empty parameter elements at the end of the parameter substring need not be included.

I am not sure that you have to assume that a default value is equivalent to zero if you were to assign the parameter element number 6 to be an alpha value. For the 38;2:...m / 48;2;...m direct colour in RGB space and the 38;3:...m / 48;3:...m (which is a direct colour in CMY space, CMY meaning the subtractive Cyan-Magenta-Yellow system that is used for printing/dyeing on to paper or other physical substrates rather then the additive process of painting light onto a display) parameter 6 has no meaning. The reason it is there is for the 38;4:...m / 48;4:...m usage which is for the direct color in CMYK - Cyan-Magenta-Yellow-blacK system which uses parameter 6 for the black component which is more efficient in conveying greyscale (uncoloured) elements (as it uses less ink) - see Wikipedia's CMYK color model for example. Given that I suspect that no-one (apart, perhaps from myself for sheer perversity 😜) is considering supporting the CMY or CMYK cases, I think you can get away with assuming that an omitted parameter 6 corresponds to a completely opaque colour when used for an alpha - but only for the RGB colour space!

As for the range of numbers to be conveyed by the parameter elements 3, 4, 5 and possibly, 6 parameter elements I guess this is where the parameter element number 2 comes in. The documentation says:

If the first parameter element has the value 2, 3, or 4, the second parameter element specifies a colour space identifier referring to a colour space definition in the document profile.

I have not seen anywhere where any values of this parameter element is defined - so I suppose everyone is treating the default case as meaning a range of 0 to 255 for the other parameters following it - so assuming a default value for the alpha parameter means a value of 255 if the second parameter is also defaulted, does seem reasonable. 🤷‍♂️

As it happens - in trying to support 24-bit colours in Mudlet (which is normally used as a graphical Multi User Dungeon client) I forgot the colour space identifier as the second parameter element (so am looking to get something fixed for Mudlet 3.16 😊 ) and we do not currently handle the colon either - so Vadi is not entirely correct about us supporting truecolor properly at present - it is more a work in progress. 😉

XVilka started this gist almost 5 years ago, documenting the state of the implementation at that time. This meant a couple of terminals noticing each other's 38;2;rrr;ggg;bbbm format and following each other.

Later did we realize that there's a standard, and that the common practice violated the standard's format of 38:2::rrr:ggg:bbbm in (at least) two ways: used incorrect separator, as well as omitted a parameter. Then some terminals (including xterm, which many others look at as reference) began to support the values according to the standard, too.

There's no way someone made up the numeric value 2 that accidentally happened to match the standard's choice, and then happened to continue differently, not knowing anything about the specs. The only reasonable explanation I can imagine is that someone found the standard, but didn't pay close attention and misinterpreted it (mind you, it's really easy to misinterpret it – at least I myself haven't spotted the skipped parameter either). That is, it's a bug, and as such, should be fixed in all affected applications.

If the common practice was a technically better solution than the standard, there'd be a lot of room for arguments which one to go for. This is not the case here. Whereas I honestly don't understand what the color-space-id is really for, it's absolutely clear that colons as separators (that is: sub-separators within the main ones) are technically superior to semicolons (that is: a flat level of separators occasionally separating independent properties, while occasionally separating subparameters of one). So, luckily, the format stated in the standard is better than the misinterpreted one. The direction everyone should be heading towards should be obvious.

[On a side note, following the pattern of colons as sub-separators, Kitty and VTE have designed and implemented (and some others have adopted too) \e[4:3m for curly underline, here colon is the only acceptable separator so that it can be distinguished from simple underline plus italic. The real credit goes to Kovid, Kitty's author for his great idea of using a colon-delimited subparameter here rather than polluting the global namespace within SGR with new numbers. (VTE even has a pending idea to introduce \e[3:1m and \e[3:2m to differentiate between italic and slanted.) As of the undercurl extension, the presence of colons is no longer specific to color sequences; emulators are supposed to generally parse them – at least within SGR – as subparameter delimiters.]

@XVilka, what do you think of refactoring the site accordingly? First, it shouldn't promote the use of the misinterpreted sequences at the top, it should show the standard's format. Second, I believe the delimiter shouldn't just be a comment in parentheses; instead, only those terminals that support the sequence according to the standard (that is: colons, and a color-space-id parameter) deserve to be mentioned under the main section listing the terminals and apps that support this feature. The rest should go to another section below, titled "support in a nonstandard way" or similar. In my opinion, an emulator not recognizing the official sequences is a bigger red flag than let's say rounding the color to the nearest 256-palette entry. IMO the document should put much stronger emphasis on whether they support true colors according to the standard, rather than whether they support true colors at all.

Those extra details for specifying italic vs. slanted and curly underlines (BTW does \e[4:1m correspond to single underline and \e[4:2m double?) is a useful and consistent way to do it! 😁

I was also lucky enough to find the ECMA-48 standard on this page here - this .pdf is from the same time frame as the ITU document but it is a little more expansive in this area; I have listed some of the ranges of characters [like this] :

5.4 Control sequences

A control sequence is a string of bit combinations starting with the control function CONTROL SEQUENCE INTRODUCER (CSI) followed by one or more bit combinations representing parameters, if any, and by one or more bit combinations identifying the control function. The control function CSI itself is an element of the C1 set.
The format of a control sequence is

CSI P ... P I ... I F

where

a) CSI is represented by bit combinations 01/11 (representing ESC) and 05/11 in a 7-bit code or by bit combination 09/11 in an 8-bit code, see 5.3;

b) P ... P are Parameter Bytes, which, if present, consist of bit combinations from 03/00 to 03/15; [which are, in order 0123456789:;<=>?]

c) I ... I are Intermediate Bytes, which, if present, consist of bit combinations from 02/00 to 02/15. [which are, in order, the space character followed by !"#$%&'()*+,-./] Together with the Final Byte F, they identify the control function;

NOTE

The number of Intermediate Bytes is not limited by this Standard; in practice, one Intermediate Byte will be sufficient since with sixteen different bit combinations available for the Intermediate Byte over one thousand control functions may be identified.

d) F is the Final Byte; it consists of a bit combination from 04/00 to 07/14; it terminates the control sequence and together with the Intermediate Bytes, if present, identifies the control function. Bit combinations 07/00 to 07/14 (i.e. pqrstuvxyz{|}~) are available as Final Bytes of control sequences for private (or experimental) use.

The definitions and the coded representations of the control functions are specified in 8.3 (see also tables 3 and 4 [omitted in this Github extract). Coding examples are shown in B.1 in annex B.
...

5.4.1 Parameter representation

A control sequence may contain a string of Parameter Bytes P ... P representing one or more parameters to complete the specification of the control function.

The Parameter Bytes are bit combinations from 03/00 to 03/15. The parameter string is interpreted as follows:

a) If the first bit combination [a.k.a Character] of the parameter string is in the range 03/00 to 03/11 [i.e. 0123456789:;], the parameter string is interpreted according to the format described in 5.4.2.

b) If the first bit combination of the parameter string is in the range 03/12 to 03/15 [i.e. <=>?], the parameter string is available for private (or experimental) use. Its format and meaning are not defined by this Standard.

5.4.2 Parameter string format

A parameter string which does not start with a bit combination in the range 03/12 to 03/15 shall have the following format:

a) A parameter string consists of one or more parameter sub-strings, each of which represents a number in decimal notation.

b) Each parameter sub-string consists of one or more bit combinations from 03/00 to 03/10; the bit combinations from 03/00 to 03/09 represent the digits ZERO to NINE; bit combination 03/10 [i.e. :] may be used as a separator in a parameter sub-string, for example, to separate the fractional part of a decimal number from the integer part of that number.

c) Parameter sub-strings are separated by one bit combination 03/11 [i.e. ;].

d) Bit combinations 03/12 to 03/15 are reserved for future standardization except when used as the first bit combination of the parameter string.

e) An empty parameter sub-string represents a default value which depends on the control function.

f) In each parameter sub-string, leading bit combinations 03/00 [i.e. 0] are not significant and may be omitted. If the parameter sub-string consists of bit combinations 03/00 only, at least one of them must be retained to indicate the zero value of the sub-string.

g) If the parameter string starts with the bit combination 03/11, an empty parameter sub-string is assumed preceding the separator; if the parameter string terminates with the bit combination 03/11, an empty parameter sub-string is assumed following the separator; if the parameter string contains successive bit combinations 03/11, empty parameter sub-strings are assumed between the separators.

h) If the control function has more than one parameter, and some parameter sub-strings are empty, the separators (bit combination 03/11) must still be present. However, if the last parameter sub-string(s) is empty, the separator preceding it may be omitted, see B.2 in annex B.

5.4.3 Types of parameters

In a control sequence with parameters, each parameter sub-string corresponds to one parameter and represents the value of that parameter. The number of parameters is either fixed or variable, depending on the control function. If the number of parameters is variable, neither the maximum number of values nor the order in which the corresponding actions are performed are defined by this Standard.

A parameter may be purely numeric or it may be selective, i.e. denoting one of a numbered list of actions the control function can perform.

In the case of selected parameters a particular parameter value may have the same meaning as a combination of two or more separate values.

Unassigned selective parameter values are reserved for future standardization.

(BTW does \e[4:1m correspond to single underline and \e[4:2m double?)

Yes, and also 4:0 for turning it off.

Oh blast, this is confusing:

The parameter values 38 and 48 are followed by a parameter substring used to select either the character foreground “colour value” or the character background “colour value”.

A parameter substring for values 38 or 48 may be divided by one or more separators (03/10) into parameter elements, denoted as Pe.

When it says the parameter values '38' and '48' are followed by a parameter substring - does this mean that the separator following the '8' should be a ':' or a ';'? There is ambiguity here because the ITU T.416 document describes the 2 that specifies a "direct colour in RGB space" as the first parameter element in the parameter substring - which suggests to me that it (the parameter substring) is a separate item and should have a major-separator (the ;) between it and the preceding 38 or 48. OTOH though, by definition either of these parameter values MUST be followed by something else so it is also conceivable that the '38' or '48' are only the first part of a complete parameter value. 😕

It's terribly confusing and I'm not sure if it can be figured out at all. It's a pity there aren't any examples.

The document uses the term "parameter substring" without defining it. I wouldn't call the next parameter a substring, to me, sub-anything means a part of the current whatever, like in strstr(3).

When it says it "may be divided [...] into parameter elements, denoted as Pe [...] indicated as: Pe : P ..." there I have no idea why it's not a "Pe : Pe : ..." instead, why only the first one is a Pe? Or why not "P : Pe : ..."? And what is P anyway?

I can see at least two problems with the interpretation I had in mind so far, namely that 38/48 are followed by a :. One is, as you say, is the off-by-one in the indexing of parameter elements in their textual description. The other one is a chicken-and-egg problem. The document clearly recognizes the number 38 or 48 first, and then goes on for processing subparameters / parameter elements, whatever they really mean. But first that 38/48 has to be located and parsed, and how is that done if the concept of parameter elements aren't defined until we locate that 38/48?

I do see a chance that they meant to use ; there, that is, the format would be like 38;2:space-id:red:green:bluem. But this assumption isn't free of problems either: there's the truly unfortunate and unjustified use of the word "substring" in this case. Plus, near the top of 13.1.8 it says "The meaning of the parameter values is shown in Table 4" and this doesn't leave room for exceptions, that is, for the "subparameter" 2:space-id:red:green:blue not to be interpreted according to this table, which would be nonsense.

Can we just conclude that the specification is unclear? And if we do, how to proceed? :)

Note that a couple of years later a technical correction was issues to T.416, but that doesn't touch any of these parts.

Not sure if it would make sense to write to ITU and ask for clarification; after 25 years probably no one there knows it any better than we do, I'm afraid we'd just ask for the interpretation of some folks who have less experience than we do. Still, could be worth a try.

I've found another bug in T-41x. Strictly speaking it's unrelated to this one; it's only worth mentioning because it shows how much we should trust these standards.

Right above the unclear wording with "parameter elements" and such, T.416 defines the mapping from SGR 30..37 and 40..47 to indexes of the default color table (note the off-by-one), and directs us to T.412. In T.412 § 9.1.4.2 the "default values" are given, with "colour specification" later being clarified to be RGB by default. Here the eight entries begin with white and black, followed by the ones where only one color channel is lit (R, G, B), followed by the ones where two are (Y, M, C). Lo and behold, this results in blue and yellow being swapped. No idea if it's a bug in the defaults in T.412 or in the mapping in T.416, but I'd guess the latter, since there's a nontrivial mapping anyway.

(And while at it, let's recall that the exact text of T.416 is also available as ISO/IEC 8613-6 for a "mere" CHF 178.)

Ah, regarding the order of colours in that 3-bit sequence of 8 colours it is logical and is based on bit pattern - and probably the electronic circuitry in the CRT monitors that use to be used for colour terminals (DEC VT241 and some later models according to: 25 Years of DEC Video Terminals):

...I'm afraid we'd just ask for the interpretation of some folks who have less experience than we do. Still, could be worth a try...

Well, I wonder whether this @tedickey is the famous maintainer of xterm and ncurses and a few other things (including lynx) - https://invisible-island.net/xterm/xterm.html is a useful resource I guess - maybe they can offer an informed view...

@egmontkob sure, will update it.

As it happens I'm updating Mudlet to handle the 16M colour SGR sequences at this time, it is simpler to parse if the separator after the 38 or 48 is : but I've had to allow for picking out a 5 and another digit sequence and a 2 and three (or optionally four, but that has to be manually selected) digit sequences out of a string of semi-colon separated argument before an m ... 🤓

Shout out to the folks using Ubuntu repos like me: I was having problems with rxvt-unicode and NeoVim, everything was solved by simply installing the package rxvt-unicode-256color on top of it, which automatically uninstalls the first one.

@pumpkinlink Beginning with Bionic, there's only a single package rxvt-unicode. (rxvt-unicode-256color is a dummy transitional package.) Your tip is a great one for users of an older Ubuntu.

FYI this fork/branch of rxvt-unicode works well with truecolors: https://github.com/da-x/rxvt-unicode/tree/v9.22-with-24bit-color

@aleek Any idea if / when that could be merged? It works pretty well in my tests here... I've submitted the patch to see if it can be included in the debian package as well: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920826

Terminator on Linux has truecolor support.

Tested on LinuxMint 19.1, Lubuntu 18.04 LTS, Debian Stretch using fish-shell.

Hello,

I would like to contribute colored terminal utilities in the NetBSD userland. By default the colors have to be disabled.

I'm thinking of:

• COLORTERM as a top-level env(1) variable, if enabled colors are emitted on tty
• *_COLORS modeled after GNU programs (LS_COLORS, PS_COLORS, ...)

Qustions:

• Can we omit ansi and 256 color palettes and switch directly to trucolors? We have a comfortable position of picking 24bits from start.
• How to design LS_COLOR for ls(1)? how to specify options there? do we need 24bit parameter for text and 24bit for background and maybe 8 bits for options (blinking, bell, etc?) -- it will look like a heavy solution to type.
• Personally I would find it useful to keep audible bell as well in *_COLORS in selected programs, e.g. to detect *.core files.

@XVilka I really love this overview but since I do not have access to all systems, programs and versions I struggle to find a proper way to detect color support properly.

So far I use a way to read multiple environment variables to verify support but as also outlined above that's not reliable. I wonder if there is a possibility to write a couple of characters and read what's written to determine if colors are supported or not (the "actual output" would only be the characters without the escape sequences for colors if the terminal supports colors).

Until there is a proper way to detect the colors, would you mind adding more information about the environment variables used by each terminal? And is there more information on terminals that support colors but not true color?

One more thing: what about moving this gist into a regular repository? That way contributing would be easier (the main content would just be the README).

https://github.com/termstandard/colors/ - see here. For now it is here.

@XVilka Great info in this gist.

Putty 0.71, with 24-bit color support, was released yesterday on 2019-03-16, see here.

Seems to work great, here an Ubuntu test from Win7 (via vagrant):

(unrelated, but very happy with this preference addition as well:)

However, most of my terminal work is on AIX (IBM ppc). This is the result:

Not quite right. Maybe you can give an educated guess on what I'm actually seeing here?

Sidenote: I use a mock bash script for seq here, since the seq binary does not exist on AIX.

AIX is always a bit more difficult when it comes to building stuff (Big Endianness, different way of libs/linking). I noticed the pre-built Bash binary I grabbed from Bull Freeware uses the AIX-native libcurses, and not libncurses. Could that be a possible reason for this behaviour?

I'm not asking you for AIX specific stuff, just if curses instead of ncurses could be a cause for this behaviour.

I've read that ncurses can often be used as a replacement for curses. I tried it the dumb way (after checking with ldd and dump -H -X64):

#AIX
[root@\_-J-A-I-L-_\.ota.hot01:/usr]# ldd `which bash`
/usr/bin/bash needs:
         /usr/lib/libc.a(shr_64.o)
         /usr/lib/libpthreads.a(shr_xpg5_64.o)
         /opt/freeware/lib/libiconv.a(libiconv.so.2)
         /usr/lib/libcurses.a(shr42_64.o)
         /usr/lib/libdl.a(shr_64.o)
         /unix
         /usr/lib/libcrypt.a(shr_64.o)
         /usr/lib/libc.a(shr.o)
         /usr/lib/libcrypt.a(shr.o)

Just a quick 'dumb' test (don't do this):

#AIX
ln -s libncurses.a /opt/freeware/lib/libcurses.a

But I had to revert that (rm the symlink) because bash failed on a missing lib (Member name shr42_64.o does not exist.). I might be able to fix that by doing a custom gcc build (or fixing the lib archive - AIX specific), but I'm by no means an expert on terminals, so I'm not even sure if the effort makes sense at all.

On Ubuntu, there is no static ldd requirement on curses nor ncurses:

#Ubuntu Xenial
vagrant@ubuntu-xenial:~$ ldd `which bash`
        linux-vdso.so.1 =>  (0x00007fff8b1fa000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fbdf54f3000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbdf52ef000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbdf4f25000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fbdf571c000)

Any ideas?

Cheers, TW

pangoterm isn't abandoned. I keep maintaining it. In fact, I'm about to add the COLORTERM environment variable to it right now.
It hasn't had many commits lately, because it's stable. It's also a relatively small wrapper program around the underlying libvterm, so it wouldn't expect to receive a lot of commits. But please don't take the lack of activity as abandonment - it's my daily use terminal, and I'm aware of a fair few users (mostly via debian) who use it daily too.

@leonerd Please add this as an issue/pull request to the new repo for this purpose: https://github.com/termstandard/colors

Please send all issues and PRs to the repo, since I didn't get email notifications when comments added in gist while getting them for the repo.
Upon updates in the repository, I will paste the contents back here.

For zoc, how to set to let it support true color? I test the version of 7.23.2，but seems that it doesn't support.(test by 24-bit-color.sh)

xterm.js now officially supports 24 bit colors (v3.13). So far only the semicolon notation is implemented.

@tw-bert Are you debugging the terminal (which term is that BTW? Putty?) or the script?
For the script, I don't think how bash is built has anything to do with the output, as the script is not using any bash primitives to set colors (I don't think bash has any!).
It's using printf command with escape sequence directly given. is AIX printf slightly different? But unlikely it correctly prints some colors but not all...

Since the affected lines are every second line, the main suspect is your seq script - does it support -1 step?! Can you paste it?

Try also the perl and awk test scripts from start of the gist, these are probably 100% portable...

[P.S. last time I played with AIX was in the 90s telnetting into my father's workstation. Then AIX curses definitely supported no colors - which led me discover ncurses, and through it I learnt all about make, gcc, configure, compiling free software. Fun times 😄]

@cben Good call, it was the seq script. Good to see all is fine on AIX as well (Putty 0.71):

A bit late, but the integrated terminal in VSCode supports True Color as of the May 2019, v1.35 update. Note that this replaces the existing approximations that were previously in use.

There is a typo in (echo -e '\e[48:2:1:2:3m\eP$qm\e\\'; xxd), no? It should be (echo -e '\e[48:2:1:2:3m\eP$qm\e\\' | xxd).

I cannot for the life of me figure out the "Querying The Terminal" section.

I even tried changing the colons to semicolons.

Terminal.app with bash and zsh on MacOS:

Alacritty SSH'd to Centos 7:

The recent "fix" was buggy. echo's output should not be piped to xxd, because in that case these sequences don't make it to the terminal at all, and xxd just prints the hexdump of the given fixed data.

echo's output must go to the terminal, to which the terminal is going to repond by synthesizing the response as if it was typed from the keyboard. This response can be printed in a friendly way using e.g. xxd which reads from the terminal as its stdin.

I understand most of your explanation and most of the original explanation, but it still does not explain how or why I should expect the terminal to provide any output when i run xxd without any arguments! Indeed, it doesn't, it just hangs waiting for input. I do not understand why, when it is run without a pipe with just a semicolon where that pipe is (currently), regardless of being inside a set of subshell parentheses, why am I to expect xxd to RECEIVE input? input from where?

Again: the terminal is going to repond by synthesizing the response as if it was typed from the keyboard. Thus it appears on xxd's standard input, provided that it's not connected elsewhere (e.g. to a faulty pipe).