Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

       Loading a theme means installing a new set of defaults.  "Erase
       Customization" should restore the theme value.  If the user wants the
       no-themes default, he should set and save bar in a Custom buffer to
       the no-themes default, thereby making the no-theme default the user
       theme value which explicitly overrides any theme, present or future.
       That is the only way one can be consistent.

   I agree.

   In what way does the current behavior differ from that?

After some checking, things are really bad.  The behavior is that with
_and_ without my patch, "Erase Customization" resets to the no-theme
default _for the current session_.  Hence my patch does not completely
fix the bug.

I suggest that, until a real fix would be installed (which will take
time), we install my patch anyway, because it will at least prevent
CVS user's .emacs from getting messed up (_even_ if they use no
themes).  My patch will be part of any real fix anyway, it just is not
the complete fix.  For people who do not use themes, it _is_ a
complete fix.

The "Themes" code is completely and hopelessly messed up.  It needs to
be rewritten from scratch.  Themes should change the standard-value
property, not the saved-value one, since they change the default
values.  There should be no user "theme", but there probably should be a
standard theme.  The "Themes" code should not try to rewrite cus-edit.
If `load-theme' and `disable-theme' correctly update the
standard-value, there is no need for Custom to know anything about
themes.  Except for one thing: there needs to be a "theme" custom
state, just to tell the user in a Custom buffer that the value was set
by a theme (other than the standard theme).  `load-theme' and
'disable-theme' should keep track of that, Custom should not have to
worry about it.  If the user uses no themes, the "Themes" code should
not be loaded at all.

This way, you do not need to understand the Themes code to understand
the Custom code (which hence gets more transparent) and bugs in the
Themes code can never mess up all of Custom.

The Themes code itself would be a lot simpler than the contorted
current mess, which nobody is able to understand and which does not
work.

For Themes to be able to handle hooks and list-vars in any
satisfactory way, the bugs in Custom concerning hooks and list-vars
would need to be fixed.

I believe that trying to fix the current Themes code is hopeless.  It
_needs_ to be rewritten from scratch.  Either we should delay
introduction of Themes until Emacs 23 (this is what I personally
recommend), or we should completely rewrite it (and probably fix the
hook bugs in Custom too) before the release.  If we want to do the
latter, we are talking about at the very least six months before a
pretest could start, probably more than a year.

Sincerely,

Luc.