[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#127943: Bug in htmlize.el
From: |
Eli Zaretskii |
Subject: |
Re: Bug#127943: Bug in htmlize.el |
Date: |
Sun, 21 Sep 2003 18:27:54 +0200 |
> Date: Sun, 21 Sep 2003 16:39:15 +0200
> From: "Eli Zaretskii" <eliz@elta.co.il>
> >
> > I'm curious -- how is "no color" different than "default (unspecified)
> > color"? Is the distinction ever useful? After all, every terminal
> > has some form of color, even when you can't change it! :-)
>
> That's true in theory; but in practice, the Emacs display code cannot
> be easily told that ``no-color'' and ``only 2 colors'' is the same. I
> don't remember the details, sorry: it was a long time ago that I
> hacked the color support for text terminals. But the fact that we
> have a display-color-p predicate is an evidence that these two
> situations are not regarded by Emacs as the same.
Actually, this is slightly inaccurate: these are the reasons why
originally the default colors used the symbol `unspecified'. As
Richard pointed out, `unspecified-fg' and `unspecified-bg' were
invented to handle inverted colors (a.k.a. reverse video) when the
colors are unknown. This happens when you invoke Emacs with the
command "emacs -nw -rv". Neither nil nor `unspecified' can handle
this situation well.