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

[Nikolai Weibull <now@bitwi.se>]

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.