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