bug#15740: 24.3.50; enabling & disabling custom themes is slow

[Drew Adams]

> > Not so, custom themes - disabling all enabled themes
> > and then enabling one theme is painfully slow, and you see all of
> > the changes manifested on the screen, slowly.  The same is true if
> > there is only one theme enabled: disabling it and enabling another
> > is very slow.
> >
> > Is this something that could be fixed?
> 
> But it works splendidly on OS X and GNU/Linux.

Are you sure?  I somehow doubt it.  Have you tried changing themes
when you have multiple frames, say 6 or 10 frames?  Try it.

> Do you have a recipe to see the slowness?

Sure.  `emacs -Q'.  Then load `doremi.el' and `doremi-cmd.el'.  Then use
`M-x doremi-custom-themes+' to cycle among themes.

With the default value of option `doremi-custom-themes-accumulate-flag',
previously enabled themes are disabled when you enable the next one.
But even in that case it is very slow.

If you let the themes accumulate while cycling (toggle that option),
then things get slower and slower and SLOWER, very quickly.  (Makes
sense: you are accumulating more stuff and disabling more stuff.)
I don't really expect cycling with accumulation to be a usable use case
(hence the default value of the option), but someone might want to use
it occasionally to merge a few themes.

And what I described is the case if you have only ONE frame.  If you
have multiple frames then it is much, much slower still.

Compared to what?  Compared to color themes.  The same library
`doremi-cmd.el' gives you command `doremi-color-themes+', for comparison.

Doesn't matter how many frames you have: replacing one *color* theme by
another appears to be instantaneous, and with no flickering (such as you
see with custom themes, where disabling runs through each frame,
redisplaying it, and then the subsequent enabling runs through each
frame again, redisplaying it).

Very simple to compare.  You will need library `color-theme.el',
available here: http://www.nongnu.org/color-theme.

The Do Re Mi files are available on Emacs Wiki:
http://www.emacswiki.org/emacs-en/download/doremi.el
http://www.emacswiki.org/emacs-en/download/doremi-cmd.el

If you want to cycle among themes using some other way than Do Re Mi,
feel free.  You'll see the same thing, I expect.
 
> > A custom theme is, I believe, heavier duty, saving more
> > information than a color theme.  A color theme records frame
> > parameters, faces, and some variables - no more.
> >
> > Does this difference in the amount of information account for the
> > difference in performance?  Dunno.  Hoping someone will take a
> > look...
> 
> Many years ago when I tried color-theme it couldn't be cleanly
> disabled and at times leave some faces in an unusable state that
> only a restart could fix.

What can I say?  Maybe you should try it again, without whatever
else you might have mixed into the bag at the time.

I have never had such a problem with it, including with Emacs 24.

And unlike custom themes, it is trivial to undo most of the effects
of a color theme, i.e., to return to whatever settings you had in
place before applying any theme.

That is apparently not possible with a custom theme - see bug #15687.
All you can do is "disable" a custom theme, which leaves you,
appearance-wise, in the same (_apparently_ themed) state.  OK,
disabling does restore `default-frame-alist` and such, but it does
not update the existing frames to restore their previous appearance.

And it is not just a redisplay thing.  If you have file foo.el in a
frame that has undergone this operation, and you want to see foo.el
in a frame that has the original settings, before you enabled and
disabled a custom theme, then you have to use `C-x 5 2' to open foo.el
in a new frame.  The existing frames are cooked, once and for all.
"Disabling" is only relative to other themes.  It is a far cry from
undoing a theme.

Don't get me wrong.  Custom themes have their strong points - they
have a relatively good Customize interface, and they include more
information than color themes do.  If the bugs get fixed then people
will perhaps rightfully be able to kiss `color-theme.el' goodbye.
Until then, custom themes are unfortunately no substitute for color
themes.