[Olivier, I'm away. Please allow me to get back to you after having a
real look]
Ben Wing <ben(a)666.com> writes:
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.
What may be is the problem, is that custom doesn't really use
specifiers. It is really is trying some emulation of the FSF frame
properties stuff. I am slowly moving custom to specifiers, but it
isn't that easy unfortunately. For the current level of support there
is the problem that we cannot use frob-face-property to set the size
of the font. This would not be difficult but it needs to be done.
What would be needed to move it to specifiers would be
1. A real font model (i.e. let the family, weight and size be
individual specifiers). Somebody really should have a look at what
FSF 21 will have. It is supposed to well design in this area.
2. Specifier tags for _all_ domains. Customize uses 'dark and 'light
tags to have different color sets for different backgrounds. There
must be some way to turn those into specifier tags. The current
solution is a cop-out (basically emulating FSF frame-properties)
but a perfect solution would be dynamic and work per window.
> Now, the question is, what is the Right Way[tm] to fix that?
Customize is supposed to work around this by (which is Not the Right Way
But Works) comparing the properties of each new frame against the
"default" and the switching to using "frame properties", i.e.
frame-locale specifiers, when the new one is different. I haven't
checked why that is failing in your case.
Jan