RE: custom-themes BAD?

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

> The by-default-cumulative behavior of themes is confusing to newbies,
> but there is already `disable-theme'.  `load-theme' does not normally
> call `disable-theme' on the rest of `custom-enable-themes' prior to
> loading a new one, but you could advice it to do so.  See also M-x
> customize-themes, which already is hooked up to enable one theme at a
> time, removing others.

As W. Greenhouse should know, `disable-theme', even applied to
all custom themes that have ever been enabled in the session,
does not restore customizations that were present before enabling
any theme.  I.e., it does not restore non-theme settings that
enabling a theme wiped out.

Put differently, you cannot "undo" the application of custom
themes, to return to the state before applying a theme.  You
can only disable custom themes relative to each other - in
general, you cannot fall back 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.

For others, unfamiliar with the bug report:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15687.
(The bug title was inappropriately renamed - the bug is not
particularly about variables.)

IMO, this represents a major deficiency of custom themes
compared to color themes (library `color-theme.el',
http://www.nongnu.org/color-theme/).

With color themes you can restore a pre-theme state.  It is
simple to take a snapshot of the current Emacs state as a
new (pseudo) theme ([Reset]), and then return to it after
enabling other themes.  What is missing for custom themes, IMO,
is the ability to take a snapshot of the current Emacs
appearance as a theme.

This, plus performance problems, mean that custom themes
cannot yet replace color themes, in general.  That's too bad;
it would be great if they could.  Custom themes do both more
and less than color themes.

(See bug #15740 about performance:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15740.)