bug-gnu-emacs
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]