GNU bug report logs - #9402
list-colors-display

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> jurta.org>

Date: Mon, 29 Aug 2011 19:55:01 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #26 received at 9402 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 9402 <at> debbugs.gnu.org, jan.h.d <at> swipnet.se
Subject: Re: bug#9402: list-colors-display
Date: Tue, 30 Aug 2011 07:41:51 -0400
> From: Juri Linkov <juri <at> jurta.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  9402 <at> 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.




This bug report was last modified 13 years and 325 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.