256-color access from __getattr__()

[Olivia5k]

I love the API where you can just to term.bold_white etc. The only thing I am missing is to be able to specify colors in the extended 256-color range in the same manner. I mostly use the blessings coloring with Logbook loggers and I use them in string formatters, passing the Terminal() object as t.

Right now I have to call the color() function to get the code out, and doing so means I need to pass the colors I want to the .format() call. It would be really awesome to be able to use {t.bold_color196} directly instead.

Would this be possible? :)

[jquast]

Alright... I've been thinking about this for over a year now(!) You do warrant some reply by now :)

I disagree with you! :)

Some background: https://gist.github.com/XVilka/8346728

In brief: if number_of_colors is 256, we can pretty safely assume to support emitting 256 colors, and this is currently possible with term.color(196) or some such. However, as a "formatting name" it is deplorable. It would require using a reference guide to map colors-by-number. I actually spent some time trying to find a mapping and came up pretty short, I guess you would run a script that emits all 256, pick the one you like, and note it down.

As an API, supporting {t.bold_color196} is very much against the "easy to write, easy to read" philosophy that Blessings encourages. What follows is my draft proposal.

rgb method

@property
def rgb(self)
   """
   Return a callable accepting arguments ``(red, green, blue)``, which emit a sequence approximated to the colorspace of the terminal bound by :attr:`number_of_colors`. The values of each color are 0-255.
(...)"""

This would be exactly like the existing color(n), except if given rgb(255, 50, 100) on a terminal where number_of_colors is 16, this would be "coerced" (or downsampled) as though you called rgb(255, 85, 85) which is exactly the expected color in the CGA palette, emitting the exact same sequence of term.bright_red or color(12).

true_colorspace context manager

@contextmanager.contextlib
def true_colorspace():
   """
   Context manager that enables mapping of compound color names and :attr:`rgb` values
   to a True color (24-bit, 16,777,216 colors) colorspace.
   """

This is necessary as a context manager: we cannot determine whether the given terminal emulator supports true colors: There is no xterm-16777216color terminal name, or anything like it. There is no situation that I know of where the terminal capability database for number_of_colors could return 16,777,216. A terminal emulator that supports it provides no method to query whether or not it supports it. For those who know their intended audience/emulator, they may rightly go ahead and use them, or provide configuration to enable it through the use of such context manager.

Compound Formatters as X11 color names

Use the official X11 color names, http://en.wikipedia.org/wiki/X11_color_names as compound formatters. These are mapped by their hexidecimal values to rgb() to emit the appropriate sequence. This allows one to use "deep_pink", which is (255, 20, 147), but on a 16-color terminal it would be mapped to the same sequence as term.bright_red.

[Olivia5k]

Wow, you've been thinking on this at levels way beyond my original suggestion, haha.

I see your reasoning to as why my suggestion would not be something desired, and I can leave it at that. It's just a nicety anyways.

I feel I can't really contribute to the inner workings you are talking about, but I am convinced that you are going to do the right thing. Keep up the good stuff! 👍

[erikrose]

+1 on rgb().

I also agree with the spirit of true_colorspace() (or maybe "true_color()" for brevity), but I feel like it might make more sense as a Terminal constructor kwarg. Is there a reason to want to push and pop its activation like location()?

[erikrose]

After sleeping on it, I realize that a mere constructor arg will not suffice: it would have to be a constructor arg that lands in a public instance var. Otherwise, it would be very cumbersome to make an interactive program which could toggle true-color mode in response to user input (which might be a common case, since we have nothing to guess based on).

[jquast]

256 and 24-bit color support is released in blessed, which is API-compatible with blessings, https://blessed.readthedocs.io/en/latest/colors.html