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