RE: RFC: Flavors - naming significant sets of customizations

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

> > The bug is not the fact that you can accumulate the effects of multiple
> > custom themes.  The bug is the fact that you cannot restore the state of
> > Emacs before any theme was applied.  There is no way to take a snapshot
> > of Emacs before theming and then restore to that.
> 
> Actually, there is: (disable-theme 'foo-theme), or globally,
> (mapcar 'disable-theme 'custom-enabled-themes).  This functionality is
> also already exposed by the M-x customize-themes GUI, which defaults to
> disabling enabled themes for enabling a new one.
> 
> The "bug", if there is one, is simply that the UI doesn't expose this
> nicely (in fact, doesn't expose it nicely for experienced users such as
> yourself to notice it).

What makes you think I didn't notice it?  Why don't you please read the
bug report?

The point is that "disabling" a custom theme only disables it relative
to other themes.  It does not *undo* the application of the theme.  It
does not restore Emacs to the state before applying the theme, even
approximately.

If you start with a customized Emacs (faces, variables, frame
parameters, whatever) and then apply a custom theme, you have no prayer
of returning to what things were like before applying the theme.

That's the point.  With color themes there is no such problem.  There
is a pseudo-theme ([Reset]) for restoring the state before theming.
It does not guarantee to restore absolutely everything, but it does a
pretty good job of things.

This important feature of color themes is missing from custom themes
(AFAICT).  You cannot take a snapshot of the Emacs state before
applying a custom theme, and then restore that snapshot state after
applying the theme.  With color themes this is trivial to do (and
fast) - the snapshot is treated more or less as a theme (call it a
pseudo-theme).

---

The other problem with custom themes (compared to color themes) is
that they are extremely slow if you have multiple frames open.

And this is the case even if you inhibit the accumulation of
themes, so that instead of each theme applied building on top of
the previous ones it just replaces the last one (so only one theme
is used at a time).

If you allow accumulation (the default behavior) then Emacs just
grinds to a halt.  Switching among color themes is super fast, no
matter how many frames there are.

Don't get me wrong - I'm glad we have custom themes.  The point
is only that, so far, they are not a sufficient *replacement* for
color themes.  Each has its advantages, so far.  Unfortunately.

Currently, if you are mainly interested in colors (e.g., faces &
frame parameters) then color-theme.el is still the way to go,
AFAICS.  If you are mainly interested in variables, then probably
custom themes are more useful.