bug#9402: list-colors-display

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@jurta.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  9402@debbugs.gnu.org
> Date: Tue, 30 Aug 2011 12:10:51 +0300
> 
> What if a user customizes a face on X for min-colors 88 and starts Emacs on
> a tty with 8 colors?

TTY is not a problem: each color goes through color approximation (see
tty-colors.el), so Emacs will choose some available color whose RGB
values are the closest to the one specified.

> Or customizes a face to "color-255" on xterm-256color
> and starts Emacs on X?  Or customizes a face for light background and
> starts Emacs on dark background?  Or customizes a face for bold and starts
> Emacs where bold is not supported?  And so on.

The answer is clear: unsupported attributes and colors are ignored,
the color approximation for TTY mentioned above being the only
exception.

> Of course, graceful degradation to some closer colors could help,
> but the result would not be what the user has customized.

What else can Emacs possibly do?

> To avoid these problems, customize-face should retain the conditional
> part of the face definition when saving the modified face.

This doesn't work in general because most faces don't provide values
for every possible level of support.

>     (((class color) (min-colors 88) (background light) (type gtk))
>      :foreground "gtk_selection_fg_color"
>      :background "gtk_selection_bg_color")

Aha, and then you run this on an older GTK version where
gtk_selection_bg_color isn't supported, then what?

The only way out of this mess that has some future is to expand the
color approximation we have for TTY to all the other display types.
That will at least work as reliably as humanly possible.  Nothing else
will ever work reliably.