`changed' theme.

[Luc Teirlinck <teirllm@dms.auburn.edu>]

I know we discussed this before, but now things just seem too obvious.

This `changed' theme makes no sense and it makes Custom unnecessarily
complex.  Even after Chong's latest change it still causes bugs, which
I will report shortly.  But the bugs are just one illustration of why
it makes no sense.

The basic problem is the following.  Somebody sets an option outside
Custom, or uses add-hook, in .emacs or during a session.  Then he
loads a theme.  Or some Emacs feature, say a minor mode, sets an
option or adds a function to a hook because it _needs_ to do so for
correct functioning and then the user loads a theme that wants to set
the option or hook.  What should happen?

If the user deliberately sat an option _through Custom_ and then loads
a Theme containing tons of options, then the Theme does not override
the explicit user customization.  An explicit user setq or other
non_Custom customization should not be overridden for exactly the same
reasons.  If an Emacs feature sat the value because it needed that
value, the Theme should not override it and make the explicitly user
enabled feature malfunction.

The problem would be especially bad when users or Emacs features add
functions to hooks or elements to listvars, which is perfectly
legitimate for them to do.  When the user then loads a theme, that
theme could completely replace the value of the hook or listvar,
thereby making Emacs features, or maybe even all of Emacs,
malfunction, for instance by removing essential functions from hooks.

Actually, themes should, in the current situation, _never_ try to set
hooks, or listvars that have to be customized with add-to-list rather
than setq.  But they might easily try it anyway.  I see no mention in
the documentation that they should not do it.  Preventing themes from
overriding any user or program customizations (whether or not done
through Custom) could at least prevent most of the worst problems
(even though not all problems).

_If_ Themes are going to override user/program "rogue" customizations,
then at least they should not try to restore the old rogue value when
the Theme gets unloaded.  This can not be implemented in any remotely
reliable way, because too much could have happened in the meantime.
They should restore the "old" value as determined by Custom.  The
current implementation has bugs, that I will report separately.

Sincerely,

Luc.