Hmm, I don't completely understand this, but it sounds like this caching
in get-custom-frame-properties is obviously wrong, right? The results
for one frame are clearly not the same as those for another frame -- this
is the whole point of specifiers! Also, does font-lock-comment-face have
tags associated with its values (e.g. (bold t) is tagged with 'mono,
etc.)? If not, that's also wrong.
Olivier Galibert wrote:
In a non-color xterm, with a .emacs that activates font-lock, do a
xemacs -nw file.c and start gnuserv
The font lock comes as bold/underline.
Then (with a good $DISPLAY), do a gnuclient file2.c.
An X frame opens, with the font-lock using _both_ bold/underline and
The reason ? 'global, i.e. fallback, specifiers values are chosen by
matching the face spec with the properties given by
(get-custom-frame-properties nil). When called with nil, the first
time this defun gets the properties of the currently selected frame.
The result (for nil) is cached, and given again all following times.
For a mono tty, the result is:
(type tty class mono background dark)
For a (default) X frame:
(type x class color background light)
For a face like font-lock-comment-face, this gives :bold t (default,
taken for mono) + :foreground blue4 (for color).
Incidentally, this is also the cause of the problem with the pdump.
The first frame coming up in that mode has these properties:
(type stream class nil background dark)
...which explains the problems I have.
Now, the question is, what is the Right Way[tm] to fix that?