bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Drew Adams]

Dunno whether this is a bug or a missing feature (enhancement request).

Custom themes were presumably inspired from the color themes of library
`color-theme.el'.  However, I do not see, for custom themes, what is an
important feature of `color-theme.el': the ability to take a snapshot of
the current settings (independent of how they were set, whether via
themes or not) as something that can function as a (pseudo)theme.

Here is a use case.  You tell me whether custom themes offer something
in this regard.

You start out with Emacs in your preferred 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') has
been applied.

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

It seems that disabling a theme is only relative to other custom themes.
Disabling does not undo the effect upon Emacs of enabling (in which case
it 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 was trivial to do: just take a
(pseudotheme) snapshot before cycling, and then restore the snapshot
upon C-g.

AFAICT, there is no equivalent of such a snapshot with custom themes,
and it's not clear how to create one.  But please prove me wrong.

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.

Please let me know if I'm missing something.  If not already available,
please provide such a useful feature: the ability to record settings as
a (pseudo)theme that is not full-blown, e.g., is not associated with a
theme file etc.

If necessary, it would be OK if the function to create such a snapshot
pseudotheme specified the particular settings to record.  Another
possibility would be to record not the current dynamic Emacs state but
the user's initial state as defined by the `custom-set-variables' and
`custom-set-faces' sexps in `(or custom-file user-init-file)'.


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-10-19 on LEG570
Bzr revision: 114715 rgm@gnu.org-20131019023520-s8mwtib7xcx9e05w
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Stefan Monnier]

retitle 15687 Disabling custom theme does not reset vars
thanks

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

I tried

   emacs -Q
   M-x custom-themes RET
   RET on the first theme to enable it
   RET again to disable it

and the settings were apparently properly reset.  Do you have a recipe
that triggers the problem?


        Stefan

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Drew Adams]

> > You enable a custom theme.  Then you disable it.  The settings remain
> > those of the "disabled" custom theme.  Your initial state is not
> > restored.
> 
> I tried
> 
>    emacs -Q
>    M-x custom-themes RET
>    RET on the first theme to enable it
>    RET again to disable it
> 
> and the settings were apparently properly reset.  Do you have a recipe
> that triggers the problem?

You skipped the first part:

 You start out with Emacs in your preferred 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')
 has been applied.

A demonstration that disabling a custom-theme can put you back to the
emacs -Q state is not too surprising.  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.

Of course, that state is not *automatically* recorded anywhere.
What's really missing, AFAICT, is the ability to take a snapshot of
the state, which can then be restored at any time.  As the bug says:

 AFAICT, there is no equivalent of such a snapshot with custom
 themes, and it's not clear how to create one.  But please prove me
 wrong.

 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.

See the full description of the bug.  And see the treatment in
color-theme.el (not my library, BTW).  There, you can take such a
snapshot at any time.  And it serves, in effect, more or less as a
theme (a pseudo theme).

As the bug report says:

 However, I do not see, for custom themes, what is an
 important feature of `color-theme.el': the ability to take a snapshot
 of the current settings (independent of how they were set, whether
 via themes or not) as something that can function as a (pseudo)theme.

Compare these commands, which cycle among themes:

1. In doremi-cmd.el: `doremi-custom-themes+' vs `doremi-color-themes+'.
2. In icicles-cmd1.el: `icicle-custom-theme' vs `icicle-color-theme'.

From the doc string of `icicle-color-theme', this part about undoing:

 If you use `C-g' during this command, the previous color-theme
 snapshot is used to restore that color theme.

 Remember too that you can use the pseudo-theme [Reset] to restore the
 last theme: `M-x color-theme-select [Reset]'.

 By default, each time you invoke this command, a snapshot is first
 made of the current color theme (or current colors, if no theme is
 used).  Thus, by default, if you use `C-g', the colors restored are
 those used before you changed themes using this command.

 However, if you use a prefix arg, then this command takes no new
 snapshot, unless no snapshot has ever been taken during this Emacs
 session.  This can be useful when experimenting, to restore not to
 the state just before this command invocation, but to some previous
 snapshot.

That part about the pseudo-them [Reset] is straight color-theme.el.
It has nothing to do with Icicles.  See color-theme.el for info
about such a snapshot.

From the doc string of `icicle-custom-theme', by contrast:

 You can use `C-g' to quit and cancel changes by the command.  Note,
 however, that some things might not be restored.  `C-g' can only
 disable any themes that you applied.  It cannot restore other
 customizations that enabling a theme might have overruled.  This is
 a limitation of Emacs custom themes: you can disable them, but you
 cannot restore non-theme settings in effect before enabling a theme.
 Color themes (and command `icicle-color-theme') do not have this
 limitation.

From the doc string of `doremi-color-themes+':

 You can use `C-g' to quit and cancel changes made so far.
 Alternatively, after using `doremi-color-themes+' you can use
 `color-theme-select' and choose pseudo-theme `[Reset]' - that does
 the same thing.  Note that in either case, some things might not
 be restored.

From the doc string of `doremi-custom-themes+':

 You can use `C-g' to quit and cancel changes made so far.  Note,
 however, that some things might not be restored.  `C-g' can only
 disable any themes that you applied.  It cannot restore other
 customizations that enabling a theme might have overruled.

----

An additional problem with custom themes, compared with color
themes, is that when multiple frames are present things become
extremely slow (maybe exponentially wrt the number of frames?
dunno).

This alone makes cycling among custom themes almost unusable
when there are multiple frames.

And this is the case even when, as is done for these cycling
commands, accumulation of custom themes is turned off.  If, on
the other hand, accumulation is allowed (the normal case for
custom themes), then things really grind to a halt.

A guess would be that this might be because custom themes record
more information than color themes.  But why this would make such
a difference, and why it might be related to the number of frames
in such a marked way, I have no idea.

If you want to see the difference, just try, say,
`doremi-custom-themes+' compared with `doremi-color-themes+',
with several frames open.  You need only the files doremi.el and
doremi-cmd.el to try that.  Both are on MELPA and on Emacs Wiki
(as are the Icicles files).

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Stefan Monnier]

>> and the settings were apparently properly reset.  Do you have a recipe
>> that triggers the problem?
> You skipped the first part:

Maybe I did, but I have a limited amount of time.  So if you don't want
to give me an actual detailed recipe I can't help you.


        Stefan

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Drew Adams]

> >> and the settings were apparently properly reset.  Do you have a recipe
> >> that triggers the problem?
> > You skipped the first part:
> 
> Maybe I did, but I have a limited amount of time.  So if you don't want
> to give me an actual detailed recipe I can't help you.

I gave a recipe.  I'll repeat it.

 emacs -Q, load oneonone.el, then doremi.el and
 doremi-cmd.el.  Then cycle among themes, using `doremi-custom-themes+'.
 Use `C-g' to cancel.  The initial state is not restored.  Nothing
 close to it.  Not for any existing frames.

And I pointed clearly to a performance problem.  Which you can also
easily see using that recipe.  And if you want to see what happens
to performance if you allow theme accumulation, just set option
`doremi-custom-themes-accumulate-flag' to t.  Bonjour les degats.

And you have it wrong.  You are not helping me.  I am helping you
(Emacs).  Trying to, anyway.  Same reason I provide such theme-cycling
commands - to help those who actually use themes (color or custom).
I, myself, do not use them.  But I still try to get them to work well.
For others.

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Glenn Morris]

Drew Adams wrote:

> I gave a recipe. I'll repeat it.
>
>  emacs -Q, load oneonone.el, then doremi.el and doremi-cmd.el.

For a laugh, I downloaded those. That's 3000 lines in total.
That is not a minimal recipe, that's "debug my code for me".
I don't have the time.
If you think this is important, please come up with a minimal recipe.

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Drew Adams]

> That is not a minimal recipe, that's "debug my code for me".

No one is asking anyone to debug my code.  The code works fine,
modulo Emacs bug #15687 and #15740.  And as I mentioned, the
code is for others, who use themes; I do not.  It is not I who
is hurt by this bug.  It is Emacs and its custom-theme users.
My aim is to help both.  If the bug report helps, fine; if not,
carry on.

I gave a simple recipe to _show the problem_.  I never claimed
that it is a minimal recipe.  I pointed to the specific code
that applies a theme and then (via C-g) tries to restore the
state.  And that code is very short and simple.

If you are not convinced that there is a problem restoring the
state as it was before applying a theme, then that quick
demonstration should convince you - without even looking at the
code - but especially if you do look at it.

After you downloaded the files "for laughs", did you even try
the theme cycling?  That's the point of downloading them, not
just to be able to laugh, poke fun, and complain about how much
you downloaded.  And that check takes only a few seconds.

Clearly, if your motivation in downloading the files was really
to look for the bug, you would at least have tried the command -
followed the recipe.  Why does my crystal ball tell me that you
didn't even try, that you just wanted to complain about how
much there was to download?

If you think that such restoration (theme undoing) is possible,
please let us know how.  (And no, `M-x customize*' is not the
answer.)  Let me put that to you positively and constructively:

How can one, with Emacs Lisp, restore the state that was in
effect before applying a custom theme?  How to _undo_ a theme
application?

Disabling a theme does not cut the mustard.  (If not convinced,
please do try the code you so patiently downloaded.  It clearly
disables all custom themes you enabled, when you hit C-g.)

The info of how to undo should be up front, in the manual.
It is not, and AFAICT it is not an accident that it is missing
altogether.  But if you know the answer, please, out with it.
In that case, this can be relegated to a doc bug, and you can
simply add that missing info to the manual to fix it.

The color-theme.el code and doc state clearly how to do that
with color themes (it is a trivial operation).  There is no
explanation of how to do that with custom themes.  Why is that?
AFAICT, there is nothing foreseen for doing that, even though it
is an obvious use case.

Is there a simple way to do it?  No answer.  If you claim there
is no bug here, please explain how that's done.  That should be
easy.  Presumably Emacs provides a simple way to do it, no?

Wrt the code to show the problem: I pointed to a simple cycling
command, whose code is short.  That should have been enough to
show, for instance, that it already does what wgreenhouse later
suggested:

 >> `disable-theme' should be called for every element in
 >> `custom-enabled-themes' before enabling a new one.

I nevertheless pointed out that the code does that:

(let ((orig-themes (delq nil (copy-sequence custom-enabled-themes)))
  ...
  (condition-case nil             ; `C-g'
      (progn (mapc #'disable-theme custom-enabled-themes)
             (if orig-themes
                 (mapc #'enable-theme orig-themes)
               (enable-theme snapshot)))
    (error nil)))

This clearly disables all enabled themes, and then enables any
themes that were enabled at the outset (i.e., were part of the
initial state).  Do you see something incorrect or missing here?

You do not need to look at 3000 lines of code to understand the
theme enabling and disabling being done.  Mauvaise foi.  And it
takes only a few seconds of trying the command to see that the
theme disabling is not enough to undo and restore the initial
state.

Keep your head in the sand and say you don't see anything.
Still, there is a bug.  Likewise, bug #15740.  If you want to
see it, raise your eyes.  If you don't want to see it, carry on.

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Drew Adams]

This bug should not have been renamed from "custom themes: disabling does not restore initial configuration" to "disabling custom theme does not reset vars".

It is *not about resetting variables*.  Not at all.

It is about restoring any number of settings that might have been changed (including customized using Customize) prior to enabling the custom theme: faces, frame parameters, etc. - as explained in this bug thread.

The point is that "disabling" a custom theme does not restore the pre-enabled state of everything that the theme changed.  Disabling only restores things relative to another custom theme.

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Stefan Monnier]

> This bug should not have been renamed from "custom themes: disabling does
> not restore initial configuration" to "disabling custom theme does not reset
> vars".
>
> It is *not about resetting variables*.  Not at all.
>
> It is about restoring any number of settings that might have been changed
> (including customized using Customize) prior to enabling the custom theme:
> faces, frame parameters, etc. - as explained in this bug thread.

We understand that.  We call that "resetting".


        Stefan

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Drew Adams]

> retitle 15687 Disabling custom theme does not reset vars
> thanks

Oh, and this should really not have been so retitled.  Please see
the bug report.  This is about restoring the configuration before
switching to a theme.  It is not just about variables.

(Probably "initial configuration" in the original title is
misleading.  I meant initial in the sense of before applying
a theme, not in the sense of initial Emacs state: emacs -Q.)

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[William G. Gardella]

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

> AFAICT, there is no equivalent of such a snapshot with custom themes,
> and it's not clear how to create one.  But please prove me wrong.

Sure.  Follow this recipe:

1) Execute "emacs -Q".

2) Customize some face.  I did M-x customize-face
   font-lock-comment-face, changing the foreground color to magenta and
   clicking "Apply."  As expected, the initial comment in the *scratch*
   buffer is now magenta.  But the choice of face doesn't really matter,
   this works with any face I tried (font-lock-builtin-face,
   font-lock-keyword-face, font-lock-function-name-face, etc.).

3) M-x customize-themes.  Choose any face you like, for example
   `manoj-dark'.  Look at the *scratch* buffer.

4) Choose another theme via M-x customize-themes.  Look at the *scratch*
   buffer.

5) Uncheck the theme checked in M-x customize-themes.  Look at the
   *scratch* buffer.

Customizeations made outside Custom themes using Customize are entirely
reversible, to the pre-themed state.

I think the confusion here--and the bug, if any--is one of user
interface and user expectations.  `load-theme', `enable-theme',
`disable-theme' et al. normally operate on one theme at a time, without
reverting all themes.  This is perhaps not such a sane default.
However, `customize-themes' disables any other active themes unless the

> [ ] Select more than one theme at a time

checkbox is checked.  Perhaps enable-theme, disable-theme etc. should
adhere to the same default, leaving at most one theme (or the pre-theme
settings) enabled at a time.

--
Best,
WGG

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Drew Adams]

Please read the bug report.  It includes the case where all themes
that have ever been applied have since been disabled.  That does not
restore all other customizations that were in effect before theming.
That's all.

If you need a recipe, emacs -Q, load oneonone.el, then doremi.el and
doremi-cmd.el.  Then cycle among themes, using `doremi-custom-themes+'.
Use `C-g' to cancel.  The initial state is not restored.  Nothing
close to it.  Not for any existing frames.

Sure, if you then create a new frame, things will look generally OK
in that frame.  But the state of any existing frames has been altered
and not restored.  Disabling a theme does not undo its effect wrt
Emacs in general.  It simply disables one theme wrt other themes
(including wrt all other themes).

In addition, I see no way to take a snapshot of the current Emacs
state as a theme, or even as a pseudo theme, to which one can revert.

This is something that is trivial with color themes - just call
`color-theme-make-snapshot'.

Try the same thing, but with command `doremi-color-themes+'.
No problem.

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[W. Greenhouse]

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

> Please read the bug report.  It includes the case where all themes
> that have ever been applied have since been disabled.  That does not
> restore all other customizations that were in effect before theming.
> That's all.

I read the bug report in detail.  Despite its length, it failed to
provide a minimal recipe for reproducing the bug.  Without it, I
essentially had to read your mind.  What I have been able to discover on
my own is that Custom themes do not prevent you from easily and
completely restoring faces altered with M-x customize.  I was able to do
so in my example.

> If you need a recipe, emacs -Q, load oneonone.el, then doremi.el and
> doremi-cmd.el.  Then cycle among themes, using `doremi-custom-themes+'.
> Use `C-g' to cancel.  The initial state is not restored.  Nothing
> close to it.  Not for any existing frames.

Since I was able to revert in the same frame completely without these
libraries, I think the problem lies not in the implementation of Custom
themes but rather the implementation for changing them in these
libraries.  To achieve a clean slate, `doremi-custom-themes' should do
exactly what `customize-themes' does: if
`custom-theme-allow-multiple-selections' is nil, `disable-theme' should
be called for every element in `custom-enabled-themes' before enabling a
new one.

> Sure, if you then create a new frame, things will look generally OK
> in that frame.  But the state of any existing frames has been altered
> and not restored.  Disabling a theme does not undo its effect wrt
> Emacs in general.  It simply disables one theme wrt other themes
> (including wrt all other themes).

Disabling a theme undoes its effect with respect to any setting made
through M-x customize.

> In addition, I see no way to take a snapshot of the current Emacs
> state as a theme, or even as a pseudo theme, to which one can revert.

(customize-create-theme) is roughly equivalent to
`color-theme-make-snapshot'.  It fills out a Custom theme using Emacs's
current state as a basis.

> This is something that is trivial with color themes - just call
> `color-theme-make-snapshot'.
>
> Try the same thing, but with command `doremi-color-themes+'.
> No problem.

As I alluded to in the last post, I think the problem lies in UI and
user expectations rather than underlying implementation.  I was never
able to get color-theme.el themes to undo themselves cleanly, because I
hadn't discovered `color-theme-make-snapshot' or your functions taking
advantage of it.

As far as I can determine from testing from emacs -Q, Custom themes
adhere to what (info "(emacs) Custom Themes") says they adhere to:

>    Any customizations that you make through the customization buffer
> take precedence over theme settings.  This lets you easily override
> individual theme settings that you disagree with.  If settings from two
> different themes overlap, the theme occurring earlier in
> `custom-enabled-themes' takes precedence.  In the customization buffer,
> if a setting has been changed from its default by a Custom theme, its
> `State' display shows `THEMED' instead of `STANDARD'.

Stuff set through Customize (whether before or after loading Custom
themes) survives enabling a theme, and those customizations will still
be there when any/all themes are disabled.  And in my own setup, which
is fairly complicated (an Emacs that's also subject to ~/.Xresources
theming as well as theming by elisp), frames do "return to normal" when
all themes are disabled.

I don't think Custom themes guarantee anything for settings made
otherwise than through M-x customize; for that case you could use
(customize-create-theme) similarly to how you'd use
(color-theme-make-snapshot) to make a point to reverse to.

--
Best,
WGG

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Drew Adams]

> To achieve a clean slate, `doremi-custom-themes[+]' should do
> exactly what `customize-themes' does: if
> `custom-theme-allow-multiple-selections' is nil, `disable-theme' should
> be called for every element in `custom-enabled-themes' before enabling a
> new one.

Did you look at the code?  What do you call this?

(let ((orig-themes (delq nil (copy-sequence custom-enabled-themes)))
  ...
  (condition-case nil             ; `C-g'
      (progn (mapc #'disable-theme custom-enabled-themes)
             (if orig-themes
                 (mapc #'enable-theme orig-themes)
               (enable-theme snapshot)))
    (error nil)))

> (customize-create-theme) is roughly equivalent to
> `color-theme-make-snapshot'.  It fills out a Custom theme using
> Emacs's current state as a basis.
...
> use (customize-create-theme) similarly to how you'd use
> (color-theme-make-snapshot) to make a point to reverse to.

No.  `customize-create-theme' opens Customize.  Show me a function
that takes a snapshot of the Emacs state, even as a custom theme,
which can then be used to restore the state.

I give up.  If you want to remain convinced there is no problem,
fine.  If you don't want to even try to see the problems reported,
using the simple recipe I gave, fine.  (Yes, simple to do: download
the files, load them into emacs -Q, and try the command.  Maybe 3
minutes altogether, including the time to download.)

I have no axe to grind about this, no dog in any race.  I provide
cycling commands for both color themes and custom themes.  And IF
it were true that the latter had no drawbacks wrt the former, I
would take pleasure in removing the code for color-theme cycling
(for Emacs versions that support custom themes).

Alas, that code needs to remain, so far.  And apparently that will
continue, as there seems to be little desire to fix the custom
theme code in this regard.  So be it.

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Lars Ingebrigtsen]

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

> Alas, that code needs to remain, so far.  And apparently that will
> continue, as there seems to be little desire to fix the custom
> theme code in this regard.  So be it.

Ok; closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Drew Adams]

> I give up.  If you want to remain convinced there is no problem,
> fine.  If you don't want to even try to see the problems reported,
> using the simple recipe I gave, fine.  (Yes, simple to do: download
> the files, load them into emacs -Q, and try the command.  Maybe 3
> minutes altogether, including the time to download.) ... there
> seems to be little desire to fix the custom theme code in this
> regard.  So be it.
>
> Ok; closing.

There is nothing OK about closing this bug.  The bug clearly
remains, and it is 100% reproducible.

And users of custom themes keep getting tripped up by this
problem.  A common, perhaps the most common, question about
custom themes is how to completely undo one.  IOW, this bug.

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Basil L. Contovounesios]

reopen 15687
quit

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

>> I give up.  If you want to remain convinced there is no problem,
>> fine.  If you don't want to even try to see the problems reported,
>> using the simple recipe I gave, fine.  (Yes, simple to do: download
>> the files, load them into emacs -Q, and try the command.  Maybe 3
>> minutes altogether, including the time to download.) ... there
>> seems to be little desire to fix the custom theme code in this
>> regard.  So be it.
>>
>> Ok; closing.
>
> There is nothing OK about closing this bug.  The bug clearly
> remains, and it is 100% reproducible.
>
> And users of custom themes keep getting tripped up by this
> problem.  A common, perhaps the most common, question about
> custom themes is how to completely undo one.  IOW, this bug.

I'm sorry if I've misunderstood something after skimming this bug
report, but I think the following recipe, starting from emacs -Q,
illustrates the central issue:

  ;; Sample custom theme touching user options and faces.
  (with-temp-file (expand-file-name "foo-theme.el" custom-theme-directory)
    (insert "\
  (deftheme foo)
  (custom-theme-set-variables 'foo '(text-quoting-style 'curved))
  (custom-theme-set-faces 'foo '(default ((t :foreground \"white\"
                                             :background \"black\"))))
  (provide-theme 'foo)\n"))

  ;; Make changes conflicting with theme `foo'.
  (setq text-quoting-style 'grave)
  (set-foreground-color "green")

  ;; Load, enable, and disable theme `foo'.
  (load-theme 'foo t)
  (disable-theme 'foo)

At the end of this, the value of text-quoting-style and the foreground
of the default face are nil and "black", respectively.  Wouldn't it be
less intrusive if they were reverted to the values they held before
enabling foo-theme, namely 'grave and "green", respectively?

Feel free to close this bug again if I've misunderstood something.

Thanks,

-- 
Basil

In GNU Emacs 27.0.50 (build 10, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2018-06-04 built on thunk
Repository revision: 1dafa4a02ed45bb4d02c6dc34c55518858422088
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Debian GNU/Linux buster/sid

bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Stefan Monnier]

> I'm sorry if I've misunderstood something after skimming this bug
> report, but I think the following recipe, starting from emacs -Q,
> illustrates the central issue:
>
>   ;; Sample custom theme touching user options and faces.
>   (with-temp-file (expand-file-name "foo-theme.el" custom-theme-directory)
>     (insert "\
>   (deftheme foo)
>   (custom-theme-set-variables 'foo '(text-quoting-style 'curved))
>   (custom-theme-set-faces 'foo '(default ((t :foreground \"white\"
>                                              :background \"black\"))))
>   (provide-theme 'foo)\n"))
>
>   ;; Make changes conflicting with theme `foo'.
>   (setq text-quoting-style 'grave)
>   (set-foreground-color "green")
>
>   ;; Load, enable, and disable theme `foo'.
>   (load-theme 'foo t)
>   (disable-theme 'foo)
>
> At the end of this, the value of text-quoting-style and the foreground
> of the default face are nil and "black", respectively.

Thanks.  Looks like a good recipe which finally describes the problem.

> Wouldn't it be less intrusive if they were reverted to the values they
> held before enabling foo-theme, namely 'grave and
> "green", respectively?

There is no question about that, yes: the code is clearly written with
the intention to reset those values to `grave` and "green".

I'm not very familiar with this code, but I know that there's some
attempt to make this work by saving the "externally modified" values
into a special theme called "changed" (as opposed to the changes made
via Custom which are saved in the special theme called "user").

So IIUC the above recipe shows that this special code either doesn't
properly save the settings to the "changed" theme, or they're not
properly used when recomputing the var's values in response to
`disable-theme`.


        Stefan