Re: Why is custom--inhibit-theme-enable not t by default?

[Daniel Colascione <dancol@dancol.org>]

On 06/18/2018 07:07 AM, Andy Moreton wrote:
> On Sun 17 Jun 2018, Andy Moreton wrote:
> 
>> On Tue 12 Jun 2018, dancol@dancol.org wrote:
>>
>>>>> Date: Mon, 11 Jun 2018 21:14:49 -0700
>>>>> From: dancol@dancol.org
>>>>>
>>>>> A simple require of a package shouldn't have side effects, especially
>>>>> not
>>>>> ones as drastic as changing the entire appearance of the program.
>>>>
>>>> I think themes are special in this regard: loading a theme activates
>>>> it.
>>>>
>>>
>>> Why did we do it that way? Is it too late to change it? Loading _anything_
>>> shouldn't activate it. I don't see a need to carve out a special case for
>>> themes.
>>>
>>> At the very least, we should make custom--inhibit-theme-enable a public
>>> variable so people can let-binding something that lets them load theme
>>> code normally without the expectation of serious side effects.
>>
>> The changes you made in commit aabaa9f8c8b7 ("Apply non-user themes only
>> when asked") break use of custom faces with use-package. E.g. in gnus:
>>
>>      (use-package gnus
>>        :custom-face
>>        (gnus-summary-selected
>>         ((((class color)) :foreground "Black" :background "PaleGoldenrod")))
>>        :config
>>        ;; other setup
>>        )
>>
>> The observed symptom is that the faces are not set correctly as specified
>> after the :custom-face keyword. However if the same buffer is viewed in
>> a new frame then it is displayed with the correct customised faces.
>>
>> This is a regression introduced by this commit - please take a look.
> 
> It appears that the change in cus-face.el in commit aabaa9f8c8b7 did not
> match the other hunks and invert the test when changing from
> `custom--inhibit-theme-enable' to `custom--should-apply-setting'.
> 
> The following patch fixes it:

Thanks. I've applied your patch.