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

[Andy Moreton]

On Tue 12 Jun 2018, address@hidden wrote:

>>> Date: Mon, 11 Jun 2018 21:14:49 -0700
>>> From: address@hidden
>>>
>>> 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.

    AndyM