* Why is custom--inhibit-theme-enable not t by default?
@ 2018-06-12 4:14 dancol
2018-06-12 15:23 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: dancol @ 2018-06-12 4:14 UTC (permalink / raw
To: emacs-devel
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?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-12 4:14 Why is custom--inhibit-theme-enable not t by default? dancol
@ 2018-06-12 15:23 ` Eli Zaretskii
2018-06-12 15:42 ` dancol
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Eli Zaretskii @ 2018-06-12 15:23 UTC (permalink / raw
To: dancol; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-12 15:23 ` Eli Zaretskii
@ 2018-06-12 15:42 ` dancol
2018-06-12 16:37 ` Eli Zaretskii
` (3 more replies)
2018-06-12 18:24 ` Basil L. Contovounesios
2018-06-13 2:16 ` Richard Stallman
2 siblings, 4 replies; 26+ messages in thread
From: dancol @ 2018-06-12 15:42 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dancol, emacs-devel
>> 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-12 15:42 ` dancol
@ 2018-06-12 16:37 ` Eli Zaretskii
[not found] ` <<83vaao3qrn.fsf@gnu.org>
` (2 subsequent siblings)
3 siblings, 0 replies; 26+ messages in thread
From: Eli Zaretskii @ 2018-06-12 16:37 UTC (permalink / raw
To: dancol; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-12 15:23 ` Eli Zaretskii
2018-06-12 15:42 ` dancol
@ 2018-06-12 18:24 ` Basil L. Contovounesios
2018-06-13 2:16 ` Richard Stallman
2 siblings, 0 replies; 26+ messages in thread
From: Basil L. Contovounesios @ 2018-06-12 18:24 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dancol, emacs-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Why is custom--inhibit-theme-enable not t by default?
[not found] ` <<83vaao3qrn.fsf@gnu.org>
@ 2018-06-12 19:54 ` Drew Adams
2018-06-13 13:47 ` Basil L. Contovounesios
0 siblings, 1 reply; 26+ messages in thread
From: Drew Adams @ 2018-06-12 19:54 UTC (permalink / raw
To: Eli Zaretskii, dancol; +Cc: emacs-devel
> > > 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-12 15:23 ` Eli Zaretskii
2018-06-12 15:42 ` dancol
2018-06-12 18:24 ` Basil L. Contovounesios
@ 2018-06-13 2:16 ` Richard Stallman
2018-06-13 13:56 ` Basil L. Contovounesios
2 siblings, 1 reply; 26+ messages in thread
From: Richard Stallman @ 2018-06-13 2:16 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dancol, emacs-devel
[[[ 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)
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-12 19:54 ` Drew Adams
@ 2018-06-13 13:47 ` Basil L. Contovounesios
2018-06-13 14:22 ` Drew Adams
0 siblings, 1 reply; 26+ messages in thread
From: Basil L. Contovounesios @ 2018-06-13 13:47 UTC (permalink / raw
To: Drew Adams; +Cc: Eli Zaretskii, dancol, emacs-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-13 2:16 ` Richard Stallman
@ 2018-06-13 13:56 ` Basil L. Contovounesios
0 siblings, 0 replies; 26+ messages in thread
From: Basil L. Contovounesios @ 2018-06-13 13:56 UTC (permalink / raw
To: Richard Stallman; +Cc: Eli Zaretskii, dancol, emacs-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-12 15:42 ` dancol
2018-06-12 16:37 ` Eli Zaretskii
[not found] ` <<83vaao3qrn.fsf@gnu.org>
@ 2018-06-13 14:01 ` Basil L. Contovounesios
2018-06-17 21:31 ` Andy Moreton
3 siblings, 0 replies; 26+ messages in thread
From: Basil L. Contovounesios @ 2018-06-13 14:01 UTC (permalink / raw
To: dancol; +Cc: Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Why is custom--inhibit-theme-enable not t by default?
2018-06-13 13:47 ` Basil L. Contovounesios
@ 2018-06-13 14:22 ` Drew Adams
2018-06-13 16:55 ` Disabling custom themes (was: Why is custom--inhibit-theme-enable not t by default?) Basil L. Contovounesios
2018-06-14 2:34 ` Why is custom--inhibit-theme-enable not t by default? Richard Stallman
0 siblings, 2 replies; 26+ messages in thread
From: Drew Adams @ 2018-06-13 14:22 UTC (permalink / raw
To: Basil L. Contovounesios; +Cc: Eli Zaretskii, dancol, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Disabling custom themes (was: Why is custom--inhibit-theme-enable not t by default?)
2018-06-13 14:22 ` Drew Adams
@ 2018-06-13 16:55 ` Basil L. Contovounesios
2018-06-13 17:16 ` Drew Adams
2018-06-14 2:34 ` Why is custom--inhibit-theme-enable not t by default? Richard Stallman
1 sibling, 1 reply; 26+ messages in thread
From: Basil L. Contovounesios @ 2018-06-13 16:55 UTC (permalink / raw
To: Drew Adams; +Cc: Eli Zaretskii, dancol, emacs-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Disabling custom themes (was: Why is custom--inhibit-theme-enable not t by default?)
2018-06-13 16:55 ` Disabling custom themes (was: Why is custom--inhibit-theme-enable not t by default?) Basil L. Contovounesios
@ 2018-06-13 17:16 ` Drew Adams
2018-06-13 17:21 ` Disabling custom themes Eric Abrahamsen
0 siblings, 1 reply; 26+ messages in thread
From: Drew Adams @ 2018-06-13 17:16 UTC (permalink / raw
To: Basil L. Contovounesios; +Cc: Eli Zaretskii, dancol, emacs-devel
> 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.).
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Disabling custom themes
2018-06-13 17:16 ` Drew Adams
@ 2018-06-13 17:21 ` Eric Abrahamsen
2018-06-13 17:30 ` Daniel Colascione
0 siblings, 1 reply; 26+ messages in thread
From: Eric Abrahamsen @ 2018-06-13 17:21 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Disabling custom themes
2018-06-13 17:21 ` Disabling custom themes Eric Abrahamsen
@ 2018-06-13 17:30 ` Daniel Colascione
0 siblings, 0 replies; 26+ messages in thread
From: Daniel Colascione @ 2018-06-13 17:30 UTC (permalink / raw
To: Eric Abrahamsen; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-13 14:22 ` Drew Adams
2018-06-13 16:55 ` Disabling custom themes (was: Why is custom--inhibit-theme-enable not t by default?) Basil L. Contovounesios
@ 2018-06-14 2:34 ` Richard Stallman
2018-06-14 3:26 ` Stefan Monnier
1 sibling, 1 reply; 26+ messages in thread
From: Richard Stallman @ 2018-06-14 2:34 UTC (permalink / raw
To: Drew Adams; +Cc: contovob, eliz, dancol, emacs-devel
[[[ 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)
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-14 2:34 ` Why is custom--inhibit-theme-enable not t by default? Richard Stallman
@ 2018-06-14 3:26 ` Stefan Monnier
2018-06-14 14:21 ` Drew Adams
0 siblings, 1 reply; 26+ messages in thread
From: Stefan Monnier @ 2018-06-14 3:26 UTC (permalink / raw
To: emacs-devel
> > > 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Why is custom--inhibit-theme-enable not t by default?
2018-06-14 3:26 ` Stefan Monnier
@ 2018-06-14 14:21 ` Drew Adams
2018-06-14 18:02 ` Stefan Monnier
0 siblings, 1 reply; 26+ messages in thread
From: Drew Adams @ 2018-06-14 14:21 UTC (permalink / raw
To: Stefan Monnier, emacs-devel
> > > > 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-14 14:21 ` Drew Adams
@ 2018-06-14 18:02 ` Stefan Monnier
2018-06-14 18:16 ` Drew Adams
0 siblings, 1 reply; 26+ messages in thread
From: Stefan Monnier @ 2018-06-14 18:02 UTC (permalink / raw
To: Drew Adams; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Why is custom--inhibit-theme-enable not t by default?
2018-06-14 18:02 ` Stefan Monnier
@ 2018-06-14 18:16 ` Drew Adams
2018-06-14 18:30 ` Stefan Monnier
0 siblings, 1 reply; 26+ messages in thread
From: Drew Adams @ 2018-06-14 18:16 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
> > 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-14 18:16 ` Drew Adams
@ 2018-06-14 18:30 ` Stefan Monnier
2018-06-14 18:41 ` Basil L. Contovounesios
0 siblings, 1 reply; 26+ messages in thread
From: Stefan Monnier @ 2018-06-14 18:30 UTC (permalink / raw
To: Drew Adams; +Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-14 18:30 ` Stefan Monnier
@ 2018-06-14 18:41 ` Basil L. Contovounesios
2018-06-14 20:09 ` Stefan Monnier
0 siblings, 1 reply; 26+ messages in thread
From: Basil L. Contovounesios @ 2018-06-14 18:41 UTC (permalink / raw
To: Stefan Monnier; +Cc: Drew Adams, emacs-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-14 18:41 ` Basil L. Contovounesios
@ 2018-06-14 20:09 ` Stefan Monnier
0 siblings, 0 replies; 26+ messages in thread
From: Stefan Monnier @ 2018-06-14 20:09 UTC (permalink / raw
To: Basil L. Contovounesios; +Cc: Drew Adams, emacs-devel
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-12 15:42 ` dancol
` (2 preceding siblings ...)
2018-06-13 14:01 ` Basil L. Contovounesios
@ 2018-06-17 21:31 ` Andy Moreton
2018-06-18 14:07 ` Andy Moreton
3 siblings, 1 reply; 26+ messages in thread
From: Andy Moreton @ 2018-06-17 21:31 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-17 21:31 ` Andy Moreton
@ 2018-06-18 14:07 ` Andy Moreton
2018-06-19 14:49 ` Daniel Colascione
0 siblings, 1 reply; 26+ messages in thread
From: Andy Moreton @ 2018-06-18 14:07 UTC (permalink / raw
To: emacs-devel; +Cc: dancol
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.
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: Why is custom--inhibit-theme-enable not t by default?
2018-06-18 14:07 ` Andy Moreton
@ 2018-06-19 14:49 ` Daniel Colascione
0 siblings, 0 replies; 26+ messages in thread
From: Daniel Colascione @ 2018-06-19 14:49 UTC (permalink / raw
To: Andy Moreton, emacs-devel
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2018-06-19 14:49 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-06-12 4:14 Why is custom--inhibit-theme-enable not t by default? dancol
2018-06-12 15:23 ` Eli Zaretskii
2018-06-12 15:42 ` dancol
2018-06-12 16:37 ` Eli Zaretskii
[not found] ` <<83vaao3qrn.fsf@gnu.org>
2018-06-12 19:54 ` Drew Adams
2018-06-13 13:47 ` Basil L. Contovounesios
2018-06-13 14:22 ` Drew Adams
2018-06-13 16:55 ` Disabling custom themes (was: Why is custom--inhibit-theme-enable not t by default?) Basil L. Contovounesios
2018-06-13 17:16 ` Drew Adams
2018-06-13 17:21 ` Disabling custom themes Eric Abrahamsen
2018-06-13 17:30 ` Daniel Colascione
2018-06-14 2:34 ` Why is custom--inhibit-theme-enable not t by default? Richard Stallman
2018-06-14 3:26 ` Stefan Monnier
2018-06-14 14:21 ` Drew Adams
2018-06-14 18:02 ` Stefan Monnier
2018-06-14 18:16 ` Drew Adams
2018-06-14 18:30 ` Stefan Monnier
2018-06-14 18:41 ` Basil L. Contovounesios
2018-06-14 20:09 ` Stefan Monnier
2018-06-13 14:01 ` Basil L. Contovounesios
2018-06-17 21:31 ` Andy Moreton
2018-06-18 14:07 ` Andy Moreton
2018-06-19 14:49 ` Daniel Colascione
2018-06-12 18:24 ` Basil L. Contovounesios
2018-06-13 2:16 ` Richard Stallman
2018-06-13 13:56 ` Basil L. Contovounesios
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.