unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* Re: Bug#127943: Bug in htmlize.el
       [not found]           ` <83ad8zryyx.wl%algernon@midgard.debian.net>
@ 2003-09-20 20:40             ` Hrvoje Niksic
  2003-09-21 12:36               ` Eli Zaretskii
  2003-09-21 13:29               ` Richard Stallman
  0 siblings, 2 replies; 6+ messages in thread
From: Hrvoje Niksic @ 2003-09-20 20:40 UTC (permalink / raw)
  Cc: bug-gnu-emacs, Peter S Galbraith, 127943

[ 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"?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bug#127943: Bug in htmlize.el
  2003-09-21 12:36               ` Eli Zaretskii
@ 2003-09-21 12:19                 ` Hrvoje Niksic
  2003-09-21 14:39                   ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Hrvoje Niksic @ 2003-09-21 12:19 UTC (permalink / raw)
  Cc: algernon, bug-gnu-emacs, psg, 127943

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bug#127943: Bug in htmlize.el
  2003-09-20 20:40             ` Bug#127943: Bug in htmlize.el Hrvoje Niksic
@ 2003-09-21 12:36               ` Eli Zaretskii
  2003-09-21 12:19                 ` Hrvoje Niksic
  2003-09-21 13:29               ` Richard Stallman
  1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2003-09-21 12:36 UTC (permalink / raw)
  Cc: algernon, bug-gnu-emacs, psg, 127943

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bug#127943: Bug in htmlize.el
  2003-09-20 20:40             ` Bug#127943: Bug in htmlize.el Hrvoje Niksic
  2003-09-21 12:36               ` Eli Zaretskii
@ 2003-09-21 13:29               ` Richard Stallman
  1 sibling, 0 replies; 6+ messages in thread
From: Richard Stallman @ 2003-09-21 13:29 UTC (permalink / raw)
  Cc: algernon, bug-gnu-emacs, psg, 127943

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bug#127943: Bug in htmlize.el
  2003-09-21 12:19                 ` Hrvoje Niksic
@ 2003-09-21 14:39                   ` Eli Zaretskii
  2003-09-21 16:27                     ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2003-09-21 14:39 UTC (permalink / raw)
  Cc: algernon, bug-gnu-emacs, psg, 127943

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bug#127943: Bug in htmlize.el
  2003-09-21 14:39                   ` Eli Zaretskii
@ 2003-09-21 16:27                     ` Eli Zaretskii
  0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2003-09-21 16:27 UTC (permalink / raw)
  Cc: algernon, bug-gnu-emacs, psg, 127943

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-09-21 16:27 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <87r8njey31.fsf@cachemir.echo-net.net>
     [not found] ` <sxsn0y61kix.fsf@florida.arsdigita.de>
     [not found]   ` <1197.1063152238@mixed>
     [not found]     ` <m3znhd54dn.fsf@xemacs.org>
     [not found]       ` <83k784rl0h.wl%algernon@bonehunter.rulez.org>
     [not found]         ` <m365jnahp7.fsf@hniksic.iskon.hr>
     [not found]           ` <83ad8zryyx.wl%algernon@midgard.debian.net>
2003-09-20 20:40             ` Bug#127943: Bug in htmlize.el Hrvoje Niksic
2003-09-21 12:36               ` Eli Zaretskii
2003-09-21 12:19                 ` Hrvoje Niksic
2003-09-21 14:39                   ` Eli Zaretskii
2003-09-21 16:27                     ` Eli Zaretskii
2003-09-21 13:29               ` Richard Stallman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).