Interaction between load-theme and custom-theme-set-faces is broken

Interaction between load-theme and custom-theme-set-faces is broken

[Nikolai Weibull]

Hi!

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.

Re: Interaction between load-theme and custom-theme-set-faces is broken

[Nikolai Weibull]

On Mon, Jul 23, 2012 at 9:30 AM, Nikolai Weibull <now@bitwi.se> wrote:

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

Have I somehow misunderstood how custom-theme-set-faces may be used?
I see no calls to it that don’t have custom--inhibit-theme-enable set
to t, so my analysis above seems correct.

Re: Interaction between load-theme and custom-theme-set-faces is broken

[Nikolai Weibull]

On Wed, Jul 25, 2012 at 7:32 PM, Nikolai Weibull <now@bitwi.se> wrote:
> On Mon, Jul 23, 2012 at 9:30 AM, Nikolai Weibull <now@bitwi.se> wrote:

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

> Have I somehow misunderstood how custom-theme-set-faces may be used?
> I see no calls to it that don’t have custom--inhibit-theme-enable set
> to t, so my analysis above seems correct.

Could someone please acknowledge that something is wrong here?

Or, if this is expected behavior, explain why?