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.