Re: Bug#127943: Bug in htmlize.el

Re: Bug#127943: Bug in htmlize.el

[Hrvoje Niksic]

[ Added Cc to bug-gnu-emacs ]

Gergely Nagy <algernon@midgard.debian.net> writes:

>> (or (face-foreground 'default)
>>     (cdr (assq 'foreground-color (frame-parameters)))
>>     "black")
>> 
>
> "unspecified-fg"
>
>> Does it really return "unspecified-fg"?  If so, I'd like to know which
>> one evaluates to that:
>> 
>>     (face-foreground 'default)
>
> This one does.
>  
>> or:
>> 
>>     (cdr (assq 'foreground-color (frame-parameters)))
>
> And this too.

I wonder... is this an Emacs bug?  How is a Lisp program supposed to
interpret "unspecified-fg" as color?  Why don't these functions return
nil instead?

Emacs bug fixers, can you help?  Is (face-foreground 'default)
supposed to return "unspecified-fg"?

Re: Bug#127943: Bug in htmlize.el

[Hrvoje Niksic]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> No, Emacs [uses those names] by design.  unspecified-fg and
> unspecified-bg are the two colors that the color support uses on
> text terminal for the foreground and background colors that the
> terminal used before Emacs starts.  IIRC (and AFAIK) most Unix text
> terminals don't allow you to query them about those colors, so their
> names and RGB values are unknown to Emacs.

Ah, that does clear things up.  That also explains why this hasn't
been reported before -- not that many people use `htmlize' on an Emacs
started in a text terminal.

>> How is a Lisp program supposed to interpret "unspecified-fg" as
>> color?
>
> It depends on the context; I don't think there's one answer to that
> question.  Please tell more about the context in this particular
> case.  Specifically, why do you need to interpret the color names at
> all?

htmlize is generating HTML that, when rendered on a color-enabled
browser, looks like the contents of the buffer.  Specifically, it
inspect buffer's fonts and colors and encodes them to HTML as closely
as possible.  Since HTML colors are in RGB, htmlize must convert a
"face" to the corresponding foreground and background RGB string.  For
example, to format the RGB components of a face's foreground color, it
calls something like:

  (apply 'format "#%02x%02x%02x"
         (mapcar (lambda (arg) (/ arg 256))
                 (x-color-values (face-foreground FACE))))

The actual code is somewhat more complex, dealing with different Emacs
versions, and supporting `face-foreground' returning nil.

So far I haven't seen face-foreground report "unspecified-*".  I think
I'll just handle it like I do nil -- default to something a bit more
sensible than throwing an error at the user.

Thanks for the explanation.

>> Why don't these functions return nil instead?
>
> Because nil means no color at all.

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!  :-)

Re: Bug#127943: Bug in htmlize.el

[Eli Zaretskii]

> From: Hrvoje Niksic <hniksic@xemacs.org>
> Date: Sat, 20 Sep 2003 22:40:24 +0200
> 
> >> (or (face-foreground 'default)
> >>     (cdr (assq 'foreground-color (frame-parameters)))
> >>     "black")
> >> 
> >
> > "unspecified-fg"
> >
> >> Does it really return "unspecified-fg"?  If so, I'd like to know which
> >> one evaluates to that:
> >> 
> >>     (face-foreground 'default)
> >
> > This one does.
> >  
> >> or:
> >> 
> >>     (cdr (assq 'foreground-color (frame-parameters)))
> >
> > And this too.
> 
> I wonder... is this an Emacs bug?

No, Emacs does so by design.  unspecified-fg and unspecified-bg are
the two colors that the color support uses on text terminal for the
foreground and background colors that the terminal used before Emacs
starts.  IIRC (and AFAIK) most Unix text terminals don't allow you to
query them about those colors, so their names and RGB values are
unknown to Emacs.

An Emacs started with "emacs -nw -q" should not change the default
colors of the terminal, it should preserve the fore- and background
colors that existed before start-up.  But it should still know that
there _are_ colors, and that they are supported by the terminal.

> How is a Lisp program supposed to interpret "unspecified-fg" as
> color?

It depends on the context; I don't think there's one answer to that
question.  Please tell more about the context in this particular case.
Specifically, why do you need to interpret the color names at all?

In general, the color names are to be interpreted by the Emacs
primitives, not by Lisp programs.  The primitives know about these two
special names, and use the `op' capability of the terminal to reset
the colors to the original ones.

There are a few exceptions to this rule, though; see faces.el.  But
the ``interpretation'' employed by faces.el is quite simple.

> Why don't these functions return nil instead?

Because nil means no color at all.  

> Is (face-foreground 'default) supposed to return "unspecified-fg"?

If the terminal doesn't allow to query its default colors, then yes.

Re: Bug#127943: Bug in htmlize.el

[Richard Stallman]

I think that unspecified-fg is used on text terminals
to help distinguish reverse video from unreversed.

Re: Bug#127943: Bug in htmlize.el

[Eli Zaretskii]

> From: Hrvoje Niksic <hniksic@xemacs.org>
> Date: Sun, 21 Sep 2003 14:19:57 +0200
> 
> So far I haven't seen face-foreground report "unspecified-*".  I think
> I'll just handle it like I do nil -- default to something a bit more
> sensible than throwing an error at the user.

I think you should not generate any HTML tags for the color of the
unspecified colors: if the result will be displayed on the text
terminal, and if htmlize doesn't give any explicit commands, the
colors you will get are the default colors.  Emacs automatically
arranges for that.

> >> Why don't these functions return nil instead?
> >
> > Because nil means no color at all.
> 
> 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.

Re: Bug#127943: Bug in htmlize.el

[Eli Zaretskii]

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