Create a gist now

Instantly share code, notes, and snippets.

True Colour (16 million colours) support in various terminal applications and terminals

Colours in terminal

It's a common confusion about terminal colours... Actually we have this:

  • plain ascii
  • ansi escape codes (16 colour codes with bold/italic and background)
  • 256 colour palette (216 colours + 16 ansi + 24 gray) (colors are 24bit)
  • 24bit true colour ("888" colours (aka 16 milion))
printf "\x1b[${bg};2;${red};${green};${blue}m\n"

The 256 colour palete is configured at start, and it's a 666 cube of colours, each of them defined as a 24bit (888 rgb) colour.

This means that current support can only display 256 different colours in the terminal, while truecolour means that you can display 16 milion different colours at the same time.

Truecolour escape codes doesnt uses a colour palete. It just specifies the colour itself.

Here's a test case:

printf "\x1b[38;2;255;100;0mTRUECOLOR\x1b[0m\n"
awk 'BEGIN{
    s="/\\/\\/\\/\\/\\"; s=s s s s s s s s;
    for (colnum = 0; colnum<77; colnum++) {
        r = 255-(colnum*255/76);
        g = (colnum*510/76);
        b = (colnum*255/76);
        if (g>255) g = 510-g;
        printf "\033[48;2;%d;%d;%dm", r,g,b;
        printf "\033[38;2;%d;%d;%dm", 255-r,255-g,255-b;
        printf "%s\033[0m", substr(s,colnum+1,1);
    printf "\n";

Keep in mind that it is possible to use both ';' and ':' as parameters delimiter.

According to Wikipedia[1], this is only supported by xterm and konsole.


Currently, there is no support for the 24-bit colour descriptions in the terminfo/termcap database and utilites. See the discussion thread here:

Here are terminals discussions:

Now supporting truecolour

But there are bunch of libvte-based terminals for GTK2 so they are listed in the another section.

Also, while this one is not exactly a terminal, but a terminal replayer, it still worth mentioning:

Parsing ANSI colour sequences, but approximating them to 256 palette

Note about colour differences: a) RGB axes are not orthogonal, so you cannot use sqrt(R^2+G^2+B^2) formula, b) for colour differences there is more correct (but much more complex) CIEDE2000 formula (which may easily blow up performance if used blindly) [2].


Terminal multiplexers

NOT supporting truecolour

[3] You can download patched version here

[4] You can download patched version here

Here are another console programs discussions:

Supporting True Colour:

Not supporting True Colour:

radare commented Feb 10, 2014

OSX default Terminal also supports truecolor


mintty does not support true color

esn89 commented Jul 6, 2014

Add this one to the list?

XVilka commented Jul 6, 2014

@PhilipDaniels @esn89 thx, added

sheerun commented Jul 6, 2014

Colors in used scheme changes with 256 color palette used by terminal. This means the same color scheme can appear differently on different terminals. It always annoyed me.

Isn't it safer to always use true color? (with fallback to 256 colors)

donatj commented Jul 6, 2014

@radare I don't know what you're talking about but mine certainly doesn't. See:


Mine doesnt either @radare/@donatj


OS X 10.9.4 does not [1] respond correctly to either the semicolon or the colon-delimeted syntaxes of the 38:2 RGB truecolor syntax [2]. The RGB, 256-color, and 16-color colon-delimited syntaxes are all ignored. The RGB semicolon syntax is ignored, exposing the bug warned of in [3], while 256-color and 16-color semicolon syntax work fine.


[2] gnachman/iTerm2@5294130#diff-af68b28e420158354052a9c17d2b2aa4R3696



Listing all libvte-based terminals and claiming that they all support truecolor is incorrect. Many of those apps rely on GTK+ version 2, and, in turn, can only use VTE version up to 0.28. Those apps do not support true colors. The ones relying on GTK+ version 3 can use a recent enough VTE (0.36 or newer) to have true colors.

DrewRWx commented Aug 22, 2014 worked for me if semicolons are used as the separators.

XVilka commented Aug 30, 2014

@egmontkob yep, i'll see the sources and mark them properly (will make a list of an old vte-based terminals)

P.S. Fixed - only 2 terminals doesn't have modern libvte support - i've marked them as unsupported.


I think it might be worth mentioning in brackets that iTerm2 only supports RGB sequences in the nightlies.

XVilka commented Oct 23, 2014

@andyherbert Thx, added in this gist!


@XVilka, thanks for putting this gist together!!

rkh commented Nov 18, 2014

Anyone figured out how to detect 24bit support to gracefully fall back to 256 colors?


@radare, Mac OSX 10.10.1 does not support truecolor. Test it by running either of these scripts in or You'll see it produces only a tiny subset of the correct spectra.

tehmaze commented Feb 9, 2015

@cwensley is using a different sequence: (not endorsing the home brew sequence here).

ZyX-I commented Mar 20, 2015

ConEmu (Windows) supports true colors as well. Don’t know about the delimiter though, but at least semicolon should be supported.


You should Putty to the list of terminals that does NOT support truecolor.

quasarj commented Apr 15, 2015

What is this "tmux_escape" workaround? There does not seem to be an option in tmux with this name (even searched the source code) and the only escape-related option is escape-time, which seems rather unrelated.

XVilka commented Apr 24, 2015

Added link to the tmux truecolor patch

rdebath commented Apr 25, 2015

@scottchiefbaker A patch exists for PuTTY to do truecolour just like XTerm, is that close enough ?

rr- commented Apr 27, 2015

I have a patch for MinTTY but it glitches as soon as the window is scrolled. Is anyone interested?

ZyX-I commented May 3, 2015

@quasarj It is possible to force tmux to send random sequences to the backing terminal unchanged. This adds truecolor “support”, but has problems: sequences will not be resent when scrolling, so you will end up with unhighlighted text. Not sure how this will behave with two panes when both are actively displaying something.

XVilka commented May 5, 2015

@rr I'm interested in, since I've started patching mintty as well (not finished though)

jerch commented May 12, 2015

I work on a browser based JS terminal emulator (still alpha), which has truecolor support now -

rr- commented May 18, 2015

I have revived the plea for adding true color support to URxvt but I got a strongly negative reception from URxvt's maintainer. To cut things short, he states that being able to render pretty images with libcaca is just not enough to add this feature upstream. That, and that it's not widely supported nor standardized, so that people wishing to use this feature would need to hardcode escape codes rather than asking terminal whether it supports this feature.
When I checked the source code myself, it seemed like URxvt is really not ready for storing RGB data. Then again I haven't been analyzing the code for too long.
@XVilka I left you a note in your commits. Basically we did almost everything the same (meaning we went through the same places in the code).


xfce4-terminal is another GTK2 libvte-based one (ie. no truecolor)

XVilka commented May 20, 2015

@unhammer Thx, added. Also noted, that this (hopefully) will be solved automatically, since Xfce slowly migrating to the GTK+3.

kuntau commented Jun 10, 2015

Anyone know why I can't have true color with mosh on remote machine? SSH working great.

halcy commented Jun 11, 2015

I made a patched-up PuTTY that DOES support real truecolor, I will try to make a proper patch (without a billion whitespace changes and based on baseline PuTTY) when I have the time, but until then, real TrueColor PuTTY.

XVilka commented Jun 15, 2015

@halcy, thanks! referenced your patched version in the gist. I hope you'll find a time to send your patch to the mainline.

XVilka commented Jun 22, 2015

mintty now has official support since commit mintty/mintty@43f0ed8

XVilka commented Jun 22, 2015

So, for now only rxvt-unicode and Terminology users can't enjoy the 16 million of colours.


@XVilka thanks for maintaining this list. Since Tmux moved to Github, the new link to the TrueColor issue is here: tmux/tmux#34

XVilka commented Jul 2, 2015

@jfelchner: thx, updated

mavey80 commented Jul 13, 2015

@rr: I ignore newbie discussions as a rule, but since this could help an otherwise worthwhile piece of SW to get better (i.e. radare), I'm gonna steer you towards fixing this in a proper and portable manner.

You're completely misrepresenting what Marc Lehmann has written. Your ignorance goes so deep, you're actually saying the exact opposite. Before you or anybody else attempts basic terminal manipulation and programming, do yourself a favor and read the following man pages, which are all already installed on your computers:
$ man terminfo
$ man toe
$ man infocmp
$ man tic

Then you can proceed to either use this information directly or follow up with reading on the ncurses documentation for higher level terminal programming API. Apart from its API, this decades existing and proven framework, which by the way is known to every UNIX programmer aspiring to at least competency-level craft, also contains a huge database of all known terminals and terminal emulators, with their respective properties and control sequences of all their features (not just ANSI). And yes, all this is also already installed on your computer.

That's what you use to build a portable application like the rest of us. You NEVER HARDCODE terminal control sequences into the application. Term. emulators set the TERM env. variable for a reason. You use it directly, or more traditionally via the curses API, to lookup an entry appropriate for the active terminal and then retrieve the required control sequences for whatever function you desire.

This is how you get an overview of the database:
$ toe -a

This is how you compare features of two different terminals (in case you needed persuasion about rxvt-unicode being technically eons in advance of all the other terminal emulators you've listed):
$ infocmp -L1 rxvt-unicode-256color vte-256color

If you absolutely must build an application independent of the entire terminfo database, e.g. a single-terminal support embedded kind of thing, this will get you the C source def's:
$ infocmp -E

Going in the reverse, to compile a terminfo/termcap definition into the binary table:
$ tic

And to get you up and running faster, you'll be looking at these capabilities:
set_a_background (setab)
set_a_foreground (setaf)
set_background (setb)
set_foreground (setf)
set_color_pair (scp)
initialize_color (initc)
orig_colors (oc)
initialize_pair (initp)
orig_pair (op)


ghost commented Jul 20, 2015

Hi all,

I have patched urxvt to support 24-bit colors:

Also, please see README.configure and the note for --enable-24-bit-color about the $TERM environment variable

This switch should break termcap/terminfo compatibility to
"TERM=rxvt-unicode-256color", and consequently set "TERM" to
"rxvt-unicode-24bit" by default but there is no termcap/terminfo
for 24-bit color support

I don't think I can change the number of colours from 256 to 16 million as I have seen programs checking specifically for 256. Anyone can help?

XVilka commented Jul 22, 2015

@spudowiar Thanks! Added your work in the gist.

ghost commented Jul 23, 2015

At the moment I keep TERM set to rxvt-unicode-256color. Any help on termcap/terminfo for 24-bit color?

XVilka commented Jul 23, 2015

@spudowiar - currently there is no way to indicate 24 bit color support via the mainstream termcap/terminfo. See the corresponding thread/messages from the ncurses maintainer
The only way is to fork terminfo/termcap or ask somehow to push the extension.

ghost commented Jul 24, 2015

Thought so. Thanks anyway!

zchee commented Aug 6, 2015

The solution for tmux.
Support tmux HEAD.

screen shot 2015-08-06 at 9 26 46 am


@zchee can you confirm this?

curl -s | bash

screen shot 2015-08-07 at 8 06 59 am

zchee commented Aug 7, 2015

@JohnMorales Perfect.

screen shot 2015-08-08 at 2 36 02 am

grawity commented Aug 19, 2015

The Linux console now understands the sequences, though it maps everything to the nearest color in the same old 16-color pallette.

XVilka commented Aug 19, 2015

@zchee Thx, added in the pad and mentioned in the corresponding tmux issue.

drydenp commented Aug 23, 2015

When you use this inside a screen session, screen will interpret the ANSI, not understand it, and print just regular grey text. It has these abilities to change the colour/boldness/highlight of text depending on rules it sets, so it's not strange that it would also mangle these RGB codes. Actually mailing them at if they have some thoughts about it.

XVilka commented Sep 3, 2015

Updated the gist, s-lang library now has support of the 24bit color

zyga commented Sep 6, 2015

Hey. I just wanted to chip in. I'm working on a similar problem from the other end. As an application, what does the terminal actually support? I keep track of this here: zyga/guacamole#15

zchee commented Sep 13, 2015

This is something to satisfy the personal desire. It is not wrote in order to lead to confusion.

zchee commented Sep 13, 2015

I hope Truecolor may be realized in the early regular way.

dequis commented Sep 18, 2015

Someone enlighten me: what is the point of using colons in the delimiters instead of semicolons? Was the difference more significant back when this was less widely supported?

jerch commented Sep 21, 2015

IMHO the colon notation makes it easier to handle false ANSI codes. Since all SGR commands are stackable within one introducer like this \x1b[0;38;2;0;0;0;7m (--> 'reset', 'rgb(0,0,0)', 'reverse') the colon thing would make it possible to parse the rgb-part as one sub-SGR rule. The semicolon variant can have side effects on any following SGR rule since it is parsed on the higher level and the parser can only guess where the rgb rule ends. Also the colon notation avoids the double meaning of the params (plain 0 as 'reset' vs. 0 after 38;2; as color value).
But the colon notation is not compatible to the original DEC syntax, a colon is not allowed within the PARAMS state there. Although the colon seems to make life easier for any parser I would stick with the semicolons. The 256-coloring also uses the semicolon with all the problems listed above and is widely adopted. Therefore the need for just another sub specification is questionable.

rdebath commented Oct 16, 2015

The original aim of the colon notation was to allow support for floating point number sequences. An ECMA-48 conforming parser is supposed to treat the ':' as another digit or a decimal point or something like that and if it doesn't understand the sequence it skips that bit. In the real world none of them do because ECMA-48 is notoriously unclear and "ITU T.416-199303" (the only 'standard' that uses this for it's colour sequences) was never publicly published. Usually an emulator will treat it like '?' or '=' and assume the entire sequence should be ignored, which is perfect in theory but breaks truecolour SGR. (OTOH the character may terminate the sequence if the parser is a little substandard, which makes SGR with just colons problematic.)

This means that the ':' vs ';' interpretations that XTerm and all the application that clone it or use it do things in slightly different ways and IMO the old sane thing an emulator can now do is to treat ':' and ';' as aliases.

This means that from the user point of view you stick with ';' as @jerch has suggested.

rdebath commented Oct 24, 2015

Okay, I've updated my PuTTY patches to include the ability to store truecolour too. I've assumed it should react the same as the XTerm 256 colour sequences for "saved cursor" and the "alternate screen". The scrollback memory cost is minimal (with a small number of colour changes). Interestingly it actually works quite well with a 256 color Windows screen.

Compiles and runs for Windows, Linux GTK font and Linux Pango.

XVilka commented Oct 26, 2015

@rdebath: have you tried to send them upstream?


Truecolor support in iTerm2 is now available in the beta builds.

rdebath commented Nov 8, 2015

@XVilka I've just asked.

Meanwhile, for this gist, it seems that the Linux Console supports the 24bit colour sequences ... and converts the colours all the way down to the 16 colours it understands!!

And thirdly, here's another nice 24bit colour tester, it shows up the difference with XTerm's fake 24bit colour quite well, it looks very 'steppy' there and smooth on truecolor.

awk 'BEGIN{
    s="/\\/\\/\\/\\/\\"; s=s s s s s s s s;
    for (colnum = 0; colnum<77; colnum++) {
        r = 255-(colnum*255/76);
        g = (colnum*510/76);
        b = (colnum*255/76);
        if (g>255) g = 510-g;
        printf "\033[48;2;%d;%d;%dm", r,g,b;
        printf "\033[38;2;%d;%d;%dm", 255-r,255-g,255-b;
        printf "%s\033[0m", substr(s,colnum+1,1);
    printf "\n";

PS: It's better in rainbow order.

rdebath commented Nov 9, 2015

I wonder how many applications support 4352 colours ?
Ncurses seems to, as does vim.


I can't go to higher bits with ncurses because it's limited to 32767 colours and the next one up, 15bpp, is 32768. But I might be able to do 31 levels per colour (29791 colours) or I could add some colour ramps, rainbows etc.

Here's a little colour dump script.

r=0; e=`tput colors`
while [ $r -lt $e ]
do  for c in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
    do  col=$((r+c))
        tput setaf $col
        echo -n " $col"
    tput sgr0
rdebath commented Dec 13, 2015

Okay, I'll ask this question ...

Does anyone know why the "colour space identifier" is missing ?

ie: from "ITU-T Rec. T.416 (1993 E)" page 41

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.

256 colour palette (216 colours + 16 gray + ansi) (colors are 24bit)

I think it should be (216 colours + 16 ansi + 24 gray).


dvtm's true color discussion.

XVilka commented Jan 29, 2016

Updated a bit, added dvtm

rr- commented Feb 16, 2016

@mavey80 I read your comment only now cause you've misspelled my handle...

You're completely misrepresenting what Marc Lehmann has written. Your ignorance goes so deep, you're actually saying the exact opposite.

Please provide specific quotes.

You NEVER HARDCODE terminal control sequences into the application.

Isn't it exactly what I've written:

That, and that it's not widely supported nor standardized, so that people wishing to use this feature would need to hardcode escape codes rather than asking terminal whether it supports this feature.


To reword: applications (including ncurses, terminfo) do not universally support 24-bit so if people want to use it, they need to use something that might accidentally work in a certain program that decided to do things in its own way, and the program would need to come up with its own code sequences that might stay in conflict with other programs. Which is bad. Which is why Marc didn't want it, because Marc wants to do things the right way (i.e. only if it gets recognized by the terminfo folk).

↑ correct me if I'm wrong here.

Ultimately, I'm afraid you mistake my role in this particular case: it's not the role of a developer, it's the role of a user. All I want is to see settings-independent RGB colors in my terminal, end of story. I'm perfectly fine with hardcoding terminal control sequences in my stupid script (which will never see light outside of my dotfiles) as well as with having to do ./configure --enable-cryptic-feature. I believe most of people here think likewise. Anything else doesn't really matter to me as the end user.

jmtd commented Feb 18, 2016

Just something else to possibly track, a library for using colours for rust programs, supports the ANSI 14 colour and extended 256 modes currently but not truecolour

kmgrant commented Feb 18, 2016

MacTerm also supports 24-bit color sequences; please add it to your list. (


cool-retro-term 1.0 ( supports True Color (tested with awk script in the gist). I don't know what version added support.

Shougo commented Apr 21, 2016

Vim 7.4.1770 supports true color.


@XVilka: do you happen to have code for 24 bit→256 color reduction done right? I've coded it once using L¹ metric with O(1) complexity (rather than L² with O(256) as xterm does), but I agree that using a proper perceptual metric would be better. I'd want it for another project of mine ( for fallback reasons.

It'd be better to do the thinking once and do it right rather than reinvent the wheel badly many times.

If such code is written, it could also be used in patches for terminals whose authors rejected proper 24 bit because of not wanting to expand their memory usage.

XVilka commented May 21, 2016 edited

@kilobyte: see this library for LAB space and this, containing conversion from RGB too.

XVilka commented May 22, 2016

Looks like XFCE Terminal release with libvte supporting true colors (the one from GTK+ 3) will be available soon:


Could someone actually test ConEmu as having 24bit TrueColour?
I am not seeing it.

sickill commented May 25, 2016 edited

Latest version of asciinema-player ( also supports true color now:

kilobyte commented Jun 1, 2016

Windows console as of Windows 10 build 14352 now understands 256/24-bit colour codes: Microsoft/BashOnWindows#76 and approximates them to 16 colour fg/16 bg (just like Linux does 16/8). This limitation is because their native console API and internal view supports only limited attributes.

XVilka commented Jun 4, 2016

For Terminator users, there is a branch for GTK+3 version, which supports true colors and much more, but it's not yet merged in the master and not yet released as well. Here is the bug for pushing it upstream. So if you want to help this - you can test it more, write patches and ping developers. Looks like this one is almost ready, I see no big stoppers against merging this branch in the master and releasing a new version of Terminator.


@XVilka Black Screen now supports true colour as well.

XVilka commented Jun 14, 2016

@shockone thanks, added in the list!

hzeller commented Jun 18, 2016

I've made an image viewer that uses the functionality:
With animated gifs on large terminals it is also a neat performance test for these terminals...

ghost commented Jun 23, 2016

@XVilka rxvt-unicode now has an alternative patch in upstream (far more efficient than my patch)

XVilka commented Jun 28, 2016

@spudowiar corrected the gist, thank you.


Quickly view (satellite) imagery directly in your terminal:

XVilka commented Jul 13, 2016

@daleroberts, @hzeller thanks, added both tools in the gist.

XVilka commented Jul 29, 2016

Xfce terminal should have support now, since the release 0.6.90. Can anyone please confirm?


Compiled and ran the following:

fornwall commented Sep 4, 2016 edited

@XVilka Termux, a terminal emulator for Android, now supports true color starting from the new 0.40 release!

Xliff commented Sep 7, 2016

Just in case people were wondering what the ${bg} meant (I did), it breaks down like follows:

38 - Extended set forground color
48 - Extended set background color

Just an FYI


@jmtd I added support for truecolor in rust-ansi-term a while back.

Elronnd commented Sep 23, 2016

For the ones that approximate the closes colour, can you mention which one of semicolons and colons they support?


@spudowiar i've compiled rxvt-unicode on ubuntu 14 LTS with --enable-everything --with-x and for whatever reason the color output is wrong. here's a screenshot. the left side is the 24 bit enabled terminal and the right side is the 256 color terminal. the 256 terminal's color cube looks correct.



Worth noting: tmux only supports 24bit colours for apps running inside of it, but does not support 24bit colours for itself.

rr- commented Oct 6, 2016

rxvt-unicode only approximates true color and still uses 88 / 256 color pallete underhood.



@rr-: Thanks, I thought I was going insane trying to get this working lol... Guess I'll try to find some other terminal to use.



XVilka commented Oct 17, 2016

Thanks, moved rxvt-unicode into a lower section. Shame they still stuck to the ultraconservative approach.

rr- commented Oct 20, 2016

mpv now supports truecolor: mpv-player/mpv@dd02369

khamer commented Oct 22, 2016

Might make sense to mention

akz92 commented Oct 23, 2016

iTerm2 supports True Color since v3 in beta builds, but v3 is now stable so it's not only in beta builds anymore.

XVilka commented Nov 8, 2016

Updated the gist, thank you.

XVilka commented Nov 15, 2016

Finally moved Midnight Commander into the 'support true color' section. See this bug for color themes for mc

XVilka commented Nov 15, 2016

For those who want to use Terminator with true color - here you can find an instruction how to build .deb

rofl0r commented Nov 16, 2016 edited

when looking at the "true color" midnight commander themes, of which none is using more than a handful of colours, i get the impression what you guys want is really just the ability to freely pick colors with an RGB value from the full range of possible 24bit colous, instead of being restricted to a hardcoded palette - but it is not actually needed to have more than 256 colors in use at the same time in a terminal window. this is already possible since a long time with the "initc" terminfo capability, which looks like


for example for xterm-256color.
ncurses supports this mode since ages, and i've written a wrapper library to use it in an easy way by just throwing RGB values at it instead of dealing with colorpairs.
i've implemented this mode also for netbsd-curses ( sabotage-linux/netbsd-curses@f824eed ) , and i do indeed think that given the ability to select whatever color with RGB values, a restriction to 256 colors at the same time on the terminal makes sense in order to keep the code simple, and resource allocation reasonable.


Windows Insiders build #14931 added true color to the windows console:

@flybayer is a beautiful new cross-platform terminal built on Electron. And it supports true color 👍

XVilka commented Nov 27, 2016

@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?

fpqc commented Dec 1, 2016

Windows 10 bash terminal now has full support

Defman21 commented Dec 5, 2016

pantheon-terminal supports true color as well.

XVilka commented Dec 6, 2016

Added Patheon Terminal as libvte-based.

XVilka commented Dec 8, 2016

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

xelra commented Dec 16, 2016 edited

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.

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.

XVilka commented Dec 21, 2016 edited

Well, I'm aware there are some unofficial extensions of terminfo

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

pickfire commented Jan 2, 2017

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.

rofl0r commented Jan 3, 2017 edited

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. (screenshot: )
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.

XVilka commented Jan 3, 2017 edited

@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.

rofl0r commented Jan 3, 2017

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

xelra commented Jan 4, 2017 edited

@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.

oconnor663 commented Jan 6, 2017 edited

I think Alacritty has truecolor support (based on this comment):

XVilka commented Jan 7, 2017

@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!

ttdoda commented Jan 13, 2017

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.

cowwoc commented Jan 18, 2017

@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 :))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment