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

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

[dancol]

A simple require of a package shouldn't have side effects, especially not
ones as drastic as changing the entire appearance of the program. Why
don't we apply themes only inside enable-theme?

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

[Eli Zaretskii]

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

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

[dancol]

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

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

[Eli Zaretskii]

> Date: Tue, 12 Jun 2018 08:42:40 -0700
> From: dancol@dancol.org
> Cc: dancol@dancol.org,
>  emacs-devel@gnu.org
> 
> > I think themes are special in this regard: loading a theme activates
> > it.
> 
> Why did we do it that way?

History, I guess.  AFAIR, it always has been that way.  Maybe we did
it for compatibility with themes that were available outside of Emacs
before Emacs supported themes?  Or maybe because themes are just giant
series of variable settings?  I really don't know.  We have this
commentary in custom.el:

  ;; Each theme is stored in a theme file, with filename THEME-theme.el.
  ;; Loading a theme basically involves calling (load "THEME-theme")
  ;; This is done by the function `load-theme'.  Loading a theme
  ;; automatically enables it.

You will see that load-theme reads the file, then evaluates the
buffer, so 'load' will do the same.

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

I honestly don't know.  I don't use themes, except for testing bugs
people report in them.  Maybe ask on reddit?

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

I'm okay with that, provided that we keep an alias with the old name.

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

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

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

FWIW, you can load a theme without activating it by specifying a non-nil
NO-ENABLE argument to load-theme.

-- 
Basil

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

[Drew Adams]

> > > I think themes are special in this regard: loading a theme activates
> > > it.
> >
> > Why did we do it that way?
> 
> History, I guess.  AFAIR, it always has been that way.  Maybe we did
> it for compatibility with themes that were available outside of Emacs
> before Emacs supported themes?

No, not if you mean color themes (`color-theme.el'). Loading
them does _not_ activate them.  There are explicit functions
for installing a color theme and invoking (activating) it.

(And unlike the case for custom themes, you can undo the
application of a color theme.)

http://www.nongnu.org/color-theme/

http://download.savannah.nongnu.org/releases/color-theme/

> Or maybe because [custom] themes are just giant
> series of variable settings?

That's possible.  Initially, custom themes were just
variable settings, IIRC - there was no attempt to
imitate color themes.  Later, Chong Yidong added such
imitation.

> I really don't know.  We have this commentary in custom.el:
> 
>   ;; Each theme is stored in a theme file, with filename THEME-theme.el.
>   ;; Loading a theme basically involves calling (load "THEME-theme")
>   ;; This is done by the function `load-theme'.  Loading a theme
>   ;; automatically enables it.
> 
> You will see that load-theme reads the file, then evaluates the
> buffer, so 'load' will do the same.
> 
> > 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.

Yes.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

Do we really want loading the file to activate the theme?

We could instead have a command to select a theme, which autoloads
the theme if necessary.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Basil L. Contovounesios]

Drew Adams <drew.adams@oracle.com> writes:

>> > > I think themes are special in this regard: loading a theme activates
>> > > it.
>> >
>> > Why did we do it that way?
>> 
>> History, I guess.  AFAIR, it always has been that way.  Maybe we did
>> it for compatibility with themes that were available outside of Emacs
>> before Emacs supported themes?
>
> No, not if you mean color themes (`color-theme.el'). Loading
> them does _not_ activate them.  There are explicit functions
> for installing a color theme and invoking (activating) it.
>
> (And unlike the case for custom themes, you can undo the
> application of a color theme.)

Doesn't the command disable-theme undo the application of a custom
theme?

-- 
Basil

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

[Basil L. Contovounesios]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I think themes are special in this regard: loading a theme activates
>   > it.
>
> Do we really want loading the file to activate the theme?
>
> We could instead have a command to select a theme, which autoloads
> the theme if necessary.

Wouldn't a simpler solution be to change the interactive spec of the
command load-theme to conditionally specify a non-nil NO-ENABLE
argument?  This argument could, for example, be toggled based on the
value of a new user option or an additional yes-or-no prompt.

WDYM by "autoload a theme", by the way, and how would that differ from
the means by which the function custom-available-themes determines which
themes are available for loading?

-- 
Basil

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

[Basil L. Contovounesios]

dancol@dancol.org writes:

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

Would this new variable / user option be able to serve as the default
interactive value of load-theme's NO-ENABLE argument?

-- 
Basil

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

[Drew Adams]

> Doesn't the command disable-theme undo the application of a custom
> theme?

No.  Summary: There is no function that takes a snapshot
of the Emacs state (even, e.g., as a custom theme) before
applying any custom theme - which snapshot can then be used
to restore that pre-theme state.

You cannot undo the application of custom themes, to return
to the state _before_ applying any theme.  You can only
disable custom themes, not undo them to a non-theme state.
You can swap one custom theme for another, but any
non-theme state before applying a custom theme is lost.

What's missing is the ability to put you back to anything
close to the pre-theme state (i.e., as much as possible),
whatever that customized state might have been. 

https://www.emacswiki.org/emacs/CustomThemes#ComparedToColorThemes

See bug #15687.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15687

Recipe:

1. You start out with Emacs in your preferred (non-theme)
customized state, a result perhaps of multiple option settings,
frame parameter settings, face settings, etc.  For example,
you have used `default-frame-alist' and customized some
particular faces.

No custom theme (except `user' - the default) has been applied yet.

2. You enable a custom theme.  Then you disable it.  The
settings remain those of the "disabled" custom theme.  Your
initial state is not restored.

Disabling does not undo the effect upon Emacs of enabling -
"disabling" is a misnomer.

Enabling not only makes a theme current but also changes
variable values, face settings, frame parameters etc., but
_none of that is part of disabling_, except in so far as
it affects or is affected by other custom themes.

The ex-theme state of Emacs is ignored wrt both enabling
and disabling.  There is no record of anything to restore.

A more precise use case: As above, but you cycle among a
set of custom themes.  You want C-g during the cycling to
cancel (i.e., undo) all effects, restoring the initial
state because you decided not to use any theme.

With `color-theme.el' this is trivial to do: just take a
(pseudotheme) snapshot before cycling, and then restore
the snapshot upon C-g.

There is no equivalent of such a snapshot with custom
themes, and it's not clear how to create one.

In particular, all of the custom-theme code requires a
theme argument, which must be defined fully, including
actually having been written to a theme file.  Hardly
something that facilitates dynamic state recording and
reverting.

FWIW, I have code that uses (e.g., cycles among)
either color themes or custom themes.  I don't "favor"
one or the other.  Each kind has its advantages.
Neither kind replaces the other.  A disadvantage of
custom themes is that you cannot undo them.

Not the end of the world, but for someone who wants to
try out themes, starting from a customized Emacs (faces,
frame parameters, etc.), it's not possible to simply
cancel out (`C-g') of the trial and return to what you
started with.

You can of course quit Emacs and start a new session,
to get back your initial, customized state.  But you
can't simply _undo_ the effect of applying a custom theme.

Disabling custom themes (was: Why is custom--inhibit-theme-enable not t by default?)

[Basil L. Contovounesios]

Drew Adams <drew.adams@oracle.com> writes:

>> Doesn't the command disable-theme undo the application of a custom
>> theme?
>
> No.  Summary: There is no function that takes a snapshot
> of the Emacs state (even, e.g., as a custom theme) before
> applying any custom theme - which snapshot can then be used
> to restore that pre-theme state.
>
> You cannot undo the application of custom themes, to return
> to the state _before_ applying any theme.  You can only
> disable custom themes, not undo them to a non-theme state.
> You can swap one custom theme for another, but any
> non-theme state before applying a custom theme is lost.
>
> What's missing is the ability to put you back to anything
> close to the pre-theme state (i.e., as much as possible),
> whatever that customized state might have been. 
>
> https://www.emacswiki.org/emacs/CustomThemes#ComparedToColorThemes
>
> See bug #15687.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15687
>
> Recipe:
>
> 1. You start out with Emacs in your preferred (non-theme)
> customized state, a result perhaps of multiple option settings,
> frame parameter settings, face settings, etc.  For example,
> you have used `default-frame-alist' and customized some
> particular faces.
>
> No custom theme (except `user' - the default) has been applied yet.
>
> 2. You enable a custom theme.  Then you disable it.  The
> settings remain those of the "disabled" custom theme.  Your
> initial state is not restored.
>
> Disabling does not undo the effect upon Emacs of enabling -
> "disabling" is a misnomer.
>
> Enabling not only makes a theme current but also changes
> variable values, face settings, frame parameters etc., but
> _none of that is part of disabling_, except in so far as
> it affects or is affected by other custom themes.
>
> The ex-theme state of Emacs is ignored wrt both enabling
> and disabling.  There is no record of anything to restore.
>
> A more precise use case: As above, but you cycle among a
> set of custom themes.  You want C-g during the cycling to
> cancel (i.e., undo) all effects, restoring the initial
> state because you decided not to use any theme.
>
> With `color-theme.el' this is trivial to do: just take a
> (pseudotheme) snapshot before cycling, and then restore
> the snapshot upon C-g.
>
> There is no equivalent of such a snapshot with custom
> themes, and it's not clear how to create one.
>
> In particular, all of the custom-theme code requires a
> theme argument, which must be defined fully, including
> actually having been written to a theme file.  Hardly
> something that facilitates dynamic state recording and
> reverting.
>
> FWIW, I have code that uses (e.g., cycles among)
> either color themes or custom themes.  I don't "favor"
> one or the other.  Each kind has its advantages.
> Neither kind replaces the other.  A disadvantage of
> custom themes is that you cannot undo them.
>
> Not the end of the world, but for someone who wants to
> try out themes, starting from a customized Emacs (faces,
> frame parameters, etc.), it's not possible to simply
> cancel out (`C-g') of the trial and return to what you
> started with.
>
> You can of course quit Emacs and start a new session,
> to get back your initial, customized state.  But you
> can't simply _undo_ the effect of applying a custom theme.

Sorry, I'm not sure I completely understand what you mean (for example
w.r.t. "initial state" and "settings of the 'disabled' custom theme"),
but I've posted a recipe with what I think you're getting at to
bug#15687, where I think any further discussion of the effects of theme
disabling can be continued.

Either way, thanks for the explanation and background.

-- 
Basil

RE: Disabling custom themes (was: Why is custom--inhibit-theme-enable not t by default?)

[Drew Adams]

> Sorry, I'm not sure I completely understand what you mean (for example
> w.r.t. "initial state" and "settings of the 'disabled' custom theme"),
> but I've posted a recipe with what I think you're getting at to
> bug#15687, where I think any further discussion of the effects of theme
> disabling can be continued.
> 
> Either way, thanks for the explanation and background.

Thanks for reopening bug #15687.  And from your post there
I think you have understood.

To try to clarify -

I mean only that custom-theme enabling/disabling knows only
about (custom) themes.  It does not know about other user
customizations, so it cannot restore them when it is disabled.

What's missing is a function that captures the state of Emacs
(anything that a custom state might modify) before any custom
theme is applied, so that that state can be restored.

Then you could (as you can with color themes) invoke that
function to take a snapshot of your Emacs before "theming",
and you could use that snapshot to restore your Emacs pretty
much as it was before "theming".

It's easy to understand if you look at what's possible with
color themes.  There, you can create a color theme (kind of
a pseudo-theme, actually) at the outset, which records the
current Emacs state as a snapshot, i.e., anything that might
be recorded in a color theme.  To restore the initial state
you need only apply that (pseudo) color theme.  Voila: back
to what you started with, as much as is practicable.

With custom themes, if the initial state before applying
a custom theme has non-default frame parameters, faces, etc.,
and if you enable and then disable a custom theme, those user
customizations are lost - not restored.  You need to quit
Emacs and restart it to get them back - and that works only
if you saved those (non-theme) customizations.

That's all.  If you start by applying a custom theme to a
virgin (`emacs -Q') session then you likely won't see the
problem.  But if you start from a customized Emacs you can.

The use case is someone who has a customized Emacs (with
those customizations saved or not), and who wants to try on
some themes, to see what they look/act like.  S?he can cycle
among themes, trying them on one after another.  But s?he
cannot get back to what s?he started with.

Why?  Because there is no custom theme that captures that
initial state, and disabling a custom theme just does so
relative to other custom themes.  The initial, default
custom theme, called `user', is not a snapshot of the
user's actual customizations (faces etc.).  

Re: Disabling custom themes

[Eric Abrahamsen]

Drew Adams <drew.adams@oracle.com> writes:

>> Sorry, I'm not sure I completely understand what you mean (for example
>> w.r.t. "initial state" and "settings of the 'disabled' custom theme"),
>> but I've posted a recipe with what I think you're getting at to
>> bug#15687, where I think any further discussion of the effects of theme
>> disabling can be continued.
>> 
>> Either way, thanks for the explanation and background.
>
> Thanks for reopening bug #15687.  And from your post there
> I think you have understood.
>
> To try to clarify -
>
> I mean only that custom-theme enabling/disabling knows only
> about (custom) themes.  It does not know about other user
> customizations, so it cannot restore them when it is disabled.
>
> What's missing is a function that captures the state of Emacs
> (anything that a custom state might modify) before any custom
> theme is applied, so that that state can be restored.
>
> Then you could (as you can with color themes) invoke that
> function to take a snapshot of your Emacs before "theming",
> and you could use that snapshot to restore your Emacs pretty
> much as it was before "theming".

I would find this useful as well. I switch to `color-theme-dark-laptop'
at night (which is very nice), and would like to be able to switch back
to my own customized state the next morning.

Re: Disabling custom themes

[Daniel Colascione]

> Drew Adams <drew.adams@oracle.com> writes:
>
>>> Sorry, I'm not sure I completely understand what you mean (for example
>>> w.r.t. "initial state" and "settings of the 'disabled' custom theme"),
>>> but I've posted a recipe with what I think you're getting at to
>>> bug#15687, where I think any further discussion of the effects of theme
>>> disabling can be continued.
>>>
>>> Either way, thanks for the explanation and background.
>>
>> Thanks for reopening bug #15687.  And from your post there
>> I think you have understood.
>>
>> To try to clarify -
>>
>> I mean only that custom-theme enabling/disabling knows only
>> about (custom) themes.  It does not know about other user
>> customizations, so it cannot restore them when it is disabled.
>>
>> What's missing is a function that captures the state of Emacs
>> (anything that a custom state might modify) before any custom
>> theme is applied, so that that state can be restored.
>>
>> Then you could (as you can with color themes) invoke that
>> function to take a snapshot of your Emacs before "theming",
>> and you could use that snapshot to restore your Emacs pretty
>> much as it was before "theming".
>
> I would find this useful as well. I switch to `color-theme-dark-laptop'
> at night (which is very nice), and would like to be able to switch back
> to my own customized state the next morning.

Wouldn't it be nice if we'd modeled visual styles on CSS? Applying a theme
would just be enabling a stylesheet. The CSS model got things
fundamentally right in a lot of ways that I think every other theme
solution only approached.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Doesn't the command disable-theme undo the application of a custom
  > > theme?

  > No.  Summary: There is no function that takes a snapshot
  > of the Emacs state (even, e.g., as a custom theme) before
  > applying any custom theme - which snapshot can then be used
  > to restore that pre-theme state.

Perhaps we should redesign the way themes work
so that a theme is represented by data that says what it does,
and we could turn it on and off.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Stefan Monnier]

>   > > Doesn't the command disable-theme undo the application of a custom
>   > > theme?
>
>   > No.  Summary: There is no function that takes a snapshot
>   > of the Emacs state (even, e.g., as a custom theme) before
>   > applying any custom theme - which snapshot can then be used
>   > to restore that pre-theme state.
>
> Perhaps we should redesign the way themes work
> so that a theme is represented by data that says what it does,
> and we could turn it on and off.

I don't think we need to redesign them, really: we simply need to say
that loading the file won't enable the theme any more.  Also loading
such a file should not have any "visible" side effect (same rule as for
Elisp packages).

If a theme needs to run arbitrary code, it simply needs to define its
own global minor mode `my-foo-mode` and then within its custom settings,
it needs to set `my-foo-mode` to t.

Themes which follow these rules should work just fine in current
Emacsen, so we can simply introduce this new rule, just like we did
(a long time ago) when we decided that loading an Elisp file
should be harmless.

AFAICT the themes bundled with Emacs already obey the rule.


        Stefan

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

[Drew Adams]

> >   > > Doesn't the command disable-theme undo the application of a
> >   > > custom theme?
> >
> >   > No.  Summary: There is no function that takes a snapshot
> >   > of the Emacs state (even, e.g., as a custom theme) before
> >   > applying any custom theme - which snapshot can then be used
> >   > to restore that pre-theme state.
> >
> > Perhaps we should redesign the way themes work
> > so that a theme is represented by data that says what it does,
> > and we could turn it on and off.
> 
> I don't think we need to redesign them, really: we simply need to say
> that loading the file won't enable the theme any more.  Also loading
> such a file should not have any "visible" side effect (same rule as for
> Elisp packages).
> 
> If a theme needs to run arbitrary code, it simply needs to define its
> own global minor mode `my-foo-mode` and then within its custom settings,
> it needs to set `my-foo-mode` to t.
> 
> Themes which follow these rules should work just fine in current
> Emacsen, so we can simply introduce this new rule, just like we did
> (a long time ago) when we decided that loading an Elisp file
> should be harmless.
> 
> AFAICT the themes bundled with Emacs already obey the rule.

AFAICS, you addressed the question of whether loading a theme
should activate it, but you did not address the point to which
you replied: disabling a custom theme does not undo it.

Maybe that point should be in a separate thread; dunno.  But
it is a separate point from the point that loading should not
enable/activate.

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

[Stefan Monnier]

> AFAICS, you addressed the question of whether loading a theme
> should activate it, but you did not address the point to which
> you replied: disabling a custom theme does not undo it.

AFAIK M-x disable-theme RET should do the trick.


        Stefan

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

[Drew Adams]

> > AFAICS, you addressed the question of whether loading a theme
> > should activate it, but you did not address the point to which
> > you replied: disabling a custom theme does not undo it.
> 
> AFAIK M-x disable-theme RET should do the trick.

No, it doesn't.  It does not restore non-theme customizations
that were in effect before you enabled the theme.

Theme "disabling" is only relative to other themes - it does
not undo the changes made by enabling the theme.

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

[Stefan Monnier]

>> AFAIK M-x disable-theme RET should do the trick.
> No, it doesn't.  It does not restore non-theme customizations
> that were in effect before you enabled the theme.

According to the code it should, so if it doesn't, it's just a bug.


        Stefan

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

[Basil L. Contovounesios]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> AFAIK M-x disable-theme RET should do the trick.
>> No, it doesn't.  It does not restore non-theme customizations
>> that were in effect before you enabled the theme.
>
> According to the code it should, so if it doesn't, it's just a bug.

I've since reopened bug#15687 to report said bug.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15687#58

-- 
Basil

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

[Stefan Monnier]

> I've since reopened bug#15687 to report said bug.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15687#58

Thanks for the recipe,


        Stefan

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

[Andy Moreton]

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.

    AndyM

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

[Andy Moreton]

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:

diff --git a/lisp/cus-face.el b/lisp/cus-face.el
index 039c1fafa7..54f5d51358 100644
--- a/lisp/cus-face.el
+++ b/lisp/cus-face.el
@@ -342,7 +342,7 @@ custom-theme-set-faces
        ;; is aliased to.
        (if (get face 'face-alias)
            (setq face (get face 'face-alias)))
-   (if (custom--should-apply-setting theme)
+ (if (not (custom--should-apply-setting theme))
            ;; Just update theme settings.
            (custom-push-theme 'theme-face face theme 'set spec)
          ;; Update theme settings and set the face spec.

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

[Daniel Colascione]

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.