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

[Drew Adams <drew.adams@oracle.com>]

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