Changes in how faces from themes are applied in 24.1?

Changes in how faces from themes are applied in 24.1?

[Nikolai Weibull]

Hi!

In 23.4, faces specified for themes would override any set before the
theme was applied.  I upgraded to 24.1 an hour ago and now I get a
merged result of what I specify in the theme and what the face is set
to before/after the theme was/is loaded.  For example, I’ve set
font-lock-variable-name-face to (:inherit default), but it also gets a
foreground of LightGoldenrod (the default as defined in font-lock.el).

How do I get the previous behavior, where the face only had the
properties listed in the specification to custom-theme-set-faces?

Re: Changes in how faces from themes are applied in 24.1?

[Eli Zaretskii]

> Date: Sun, 22 Jul 2012 19:07:00 +0200
> From: Nikolai Weibull <now@bitwi.se>
> 
> How do I get the previous behavior, where the face only had the
> properties listed in the specification to custom-theme-set-faces?

Does it help to have a non-nil NOW member of the forms in the argument
list to custom-theme-set-faces?

Re: Changes in how faces from themes are applied in 24.1?

[Nikolai Weibull]

On Sun, Jul 22, 2012 at 7:21 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 22 Jul 2012 19:07:00 +0200
>> From: Nikolai Weibull <now@bitwi.se>
>>
>> How do I get the previous behavior, where the face only had the
>> properties listed in the specification to custom-theme-set-faces?

> Does it help to have a non-nil NOW member of the forms in the argument
> list to custom-theme-set-faces?

Sorry, I should have mentioned that a non-nil NOW member seems to have
no effect.

Re: Changes in how faces from themes are applied in 24.1?

[Nikolai Weibull]

On Sun, Jul 22, 2012 at 7:51 PM, Nikolai Weibull <now@bitwi.se> wrote:
> On Sun, Jul 22, 2012 at 7:21 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Date: Sun, 22 Jul 2012 19:07:00 +0200
>>> From: Nikolai Weibull <now@bitwi.se>
>>>
>>> How do I get the previous behavior, where the face only had the
>>> properties listed in the specification to custom-theme-set-faces?
>
>> Does it help to have a non-nil NOW member of the forms in the argument
>> list to custom-theme-set-faces?
>
> Sorry, I should have mentioned that a non-nil NOW member seems to have
> no effect.

After further investigation there seems to be a problem with how
custom--inhibit-theme-enable is used when considering how
custom-theme-set-faces is implemented and how other functions depend
on how it sets things up.  I posted the following on the dev list:

It seems that the interaction between load-theme and
custom-theme-set-faces is broken.  Previously, before a commit on
2011-03-21 that changed how custom--inhibit-theme-enable was used,
custom-theme-set-faces would do quite a bit of work (setting
properties) that other code depends upon (unless
custom--inhibit-theme-enable was t, of course).  For example, it would
set 'saved-face, which face-spec-recalc checks for to determine how it
should recalculate the specification of a face.  As this code is no
longer executed (ever, it seems, as custom--inhibit-theme-enable is
never logically non-t while it’s being executed), this is now broken,
which means that faces set through themes will always be a combination
of the face-default-spec of the face and the spec of the theme.

The same goes for custom-theme-set-variables, but isn’t as visually apparent.