256-color support

[erikrose]

Think about supporting 256-color palettes. If we do it, we should either be able to detect whether it's supported (via $TERM, or is there a cap we can check?) and/or provide transparent fallback to the nearest available color.

[erikrose]

For how to do 88-color stuff, see ~/Downloads/terminal-colors.py.

[erikrose]

We can now detect whether it's supported via number_of_colors. We might also want to provide fallback—undecided.

[erikrose]

From a reddit post by pheonix1701 (http://www.reddit.com/r/programming/comments/yeudv/blessings_15_a_python_replacement_for_curses/c5v05eo)...

This is amazing. Lovely API. Only thing missing that I'd like to see is an rgb() method that uses the index of the color that's closest to the color whose RGB components are passed as arguments. Here's an implementation for 256-color terminals:

def rgb(self, r, g, b): if r == g == b: offset = int(r / (256.0 / 24.0)) index = 232 + offset else: roundint = lambda n, p: (n + p / 2) / p * p

Technically this ought to clamp to 0x5f, 0x87, 0xaf, and 0xd7

rather than 0x33, 0x66, 0x99, and 0xcc, but who the hell came

up with that? Seriously.

clamped_r = roundint(r, 0x33) clamped_g = roundint(g, 0x33) clamped_b = roundint(b, 0x33)

col = clamped_b / 0x33 row = clamped_g / 0x33 face = clamped_r / 0x33 index = 36 * face + 6 * row + col + 16

return self.color(index)

You're welcome to steal that.

[jquast]

This looks like an elegant solution to the problem, http://pydoc.net/Python/Pygments/1.4/pygments.formatters.terminal256/

the method _closest_color could be modified to use .number_of_colors, and scan only the 256-color range on 256-color terminals, and only the 16 color range on 16-color terminals, which would allow rgb() values to map to the basic 16-bit color set.

[exhuma]

For clarification:

I just tried the following:

t = Terminal()
print t.color(240)('foo')

It returned the expected result for a 256 colour terminal. Using values below 0 returned text with the default foreground, values above 255 wrapped around. So the colour for 256 is the same as the colour for 0. This wrapping behaviour seems to be only true for a 256 colour terminal (I have not tested an 88-colour term though).

Given the internal code, this seems to be the behaviour of curses. I'm not quite sure about the _resolve_color method though. Given my limited knowledge of curses, I had a bit of trouble following it.

So essentially, 256 colour support is already a thing of reality. A closest_color(r, g, b) function might be a nice-to-have feature though.

[jquast]

I designed a draft proposal in issues #67

[richrd]

Hi! I'm the author of Suplemon (https://github.com/richrd/suplemon) and I've been thinking of ditching curses. Blessings seems like a good fit, but I need 256 color support. This feature would be awesome! EDIT: apparently they're available via exhuma's suggested method t.color(240). Great :+1:

[jquast]

Blessed supports 24-bit and 256 colors, and is API compatible with blessings. https://blessed.readthedocs.io/en/latest/colors.html

All X11 colors are available (hundreds? thousands?) in addition to the traditional 16 that blessings provides, and the nearest color is used for terminals only supporting 256 or 16 colors (at a bit of a cpu cost). All 24-bit colors are available using color_rgb and on_color_rgb functions.

special thanks to @avylove who helped write most of it!