[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel Colascione
Subject: Re: Why is custom--inhibit-theme-enable not t by default?
Date: Tue, 19 Jun 2018 07:49:05 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 06/18/2018 07:07 AM, Andy Moreton wrote:
On Sun 17 Jun 2018, Andy Moreton wrote:

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
ones as drastic as changing the entire appearance of the program.

I think themes are special in this regard: loading a theme activates

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

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
        ((((class color)) :foreground "Black" :background "PaleGoldenrod")))
       ;; 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]