Skip to content


Subversion checkout URL

You can clone with
Download ZIP


256-color terminal support #4

laanwj opened this Issue · 27 comments

4 participants


Very nice project, I've been pondering abut something like this for a while, and existing Python console support projects seem to have died a quiet death.

A small feature request: Most terminals these days support 256 color (gnome, konsole, even old xterm/mrxvt). It'd be awesome if you could use these colors in Clint (for example, by setting colors as RGB and choosing the closest color). We're now in 2011 and 8-color text is old-fashioned :)

I might get around to implementing this myself and submitting a patch. I have code for this in one of my other projects. (As for lists of R/G/B values, and/or color names, IPython could be an inspiration as it has a module for it)


Thanks! :)

I've been considering something like this for a while now, but wasn't sure about cross platform support. Does the windows terminal support 256?

Possible API:

from clint.textui import colored

colored.rgb('3f3f3f', 'Special colored text')

That API looks good.

I'm not sure about the Windows terminal, it's probably too wired to the old DOS-age (Putty does seem to support it with some settings enabled -- ).

But indeed, fact is that not all terminals support it, so it either needs detection (preferable) and/or a user-specified flag to enabled it.

In case of 8/16 colors, a fallback is needed to choose the closest color available.

Edit: found a pretty recent negative w/o Windows console 256 color support:



colored.rgb('#3f3f3f', 'Special colored text')
colored.rgb('3f3f3f', 'Special colored text')
colored.rgb(('3f', '3f', '3f'), 'Special colored text')
colored.rgb((100, 24, 244), 'Special colored text')

Also, standard html colors support:

colored.rgb('lightcyan', 'Cyan Text')

It looks like the HTML colors map pretty well to xterm256 colors:


I've now put the code in some self-contained modules. Conversion of RGB from/to HTML color:

Conversion of RGB from/to xterm256 color:

Both use the same colorconv.<xxx>.from_rgb / to_rgb interface. I'll make a similar module for ansi, as fallback. This is simple, but ambiguous, as ANSI colors are not fixed in RGB space as the HTML/xterm256 ones.

Then I'll go integrate this into Clint.



You, sir, are a gentleman and a scholar. :cake:


btw, are those clint columns? :P


Not yet, at the moment they are improvised columns :)


I've implemented the API support in my fork:

I've added an example to showcase it (using Clint columns :P).

Open issue

  • Is it possible to detect terminal color support? Currently it defaults to ANSI16 unless the user sets otherwise. For xterm/putty/GNOME it could pick 256 colors, and for konsole 24 bit RGB.
@laanwj laanwj was assigned

Fantastic! I'm playing with it now.

Can you send a pull request from your xterm256 branch to my feature/256 branch?


Hmm, this breaks the regular'string') capability for some reason.


Couldn't send a pull request, I think you already synced it.

OK strange I'll take a look.


Solved in my branch, I had forgotten a getattr.


@laanwj thank you sir!

As soon as we can figure out how to detect a terminal's color capabilities and disable 256 when it's not available, I'll merge this in.


Did a little research on that,

To conclude: it's complicated (except on Windows).


I'm thinking of building an internal table of supported terminal emulators.



I see you removed the colorama intitialisation, why is that? I think colorama init would be a good place to put the TERM-based detection?


@laanwj, the colorama.init call tells colorama to automatically send a reset color after anything is printed, which is unnecessary because ColoredString already ends them with a reset.


I read the linked doc but I don't know why tput colors is not a good method.

The “tput colors” command shows the amount of colors specified in the terminfo entry specief by TERM.

So this means in theory there would not be any need to keep a list of supported TERMs. If tput colors says 8, it's up to the user to configure the terminal to display more colors, and clint should probably do what other programs do, fall back to an approximate value within those available colors.

What is really blockiing this merge?


Yes, in theory you're right. But if you want it to work out of the box in for example Ubuntu (gnome terminal), just taking the tput value for granted is not enough. It returns 8... :(


That's right, but what I mean is that we still should rely on what tput says. Other programs like Vim or Tmux use the 8 color approximations until I set the TERM properly. It's a pain, but the bug is in the distros or the terminals, I guess. It shouldn't be a blocker for Clint, I think.


Fine with me, the checks for TERM/COLORTERM can always be added in later.


Can we please retake this?


@kennethreitz @laanwj Is this code anywhere still? I'd like to take a look and try to make it work based on what tput says, but I could find no PR or branch with it. I'm so looking forward to outputting crazy colours! :)


@jdevera I never submitted a pull request somehow. But the code is still here:


I'm going to pick this back up and hopefully get it in clint soon :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.