Re: Starnge comment in Custom Theme code.

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

Chong Yidong wrote:

   I don't know what your belly-aching is supposed to accomplish;

Mainly to try to prevent the Custom Theme code from negatively
affecting the general functioning of the non-theme Custom.  Unless
certain issues are satisfactorily resolved, it will.  If these issues
can not be resolved before the release, Custom Themes should quite
simply not be part of the release.

Trying to fix bugs in Custom Themes can easily produce bugs in the
non-theme Custom.  In addition a major problem with Custom Themes
(apart from its bugs) is that to safely make some changes,
enhancements or even bug fixes to Custom, you sometimes have to know
every detail about Custom themes.  These details are vague and
ill-defined, which is a problem in itself, but made worse by the
previous fact.

I believed that we made substantial progress on the issue of clearly
and _simply_ defining what Custom themes are a few days ago.
(Unfortunately, some things you said today put this in doubt again.)
I believe that we decided that a Custom theme was an alternative
standard value, that is, setting a value through a Theme is completely
equivalent with specifying an alternative expression in the defcustom.
If we would _consistently_ stick with that (which implies that Custom
Themes do not override setq) and also consistently stick with the fact
that Themes are stored in separate files loaded in .emacs and that
Custom has nothing to do with it, then Custom Themes would no longer
be the big obstacle to safely making changes in Custom that they are
now.  People would know what Custom Themes are supposed to do without
understanding their code in full detail.

We should remove all Custom Theme code that conflicts with the above
straightforward definition of a Custom Theme and all code that tries to
write into .emacs on behalf of Custom themes.  That would be a big
improvement.  (What about these four lines in `custom-save-variables'
I asked you to explain?)

In addition, things would be a _lot_ cleaner if the theme value got
stored in the standard-value property, to be consistent the above
definition.  Then it would be once again completely safe to make
changes in Custom without worrying about Custom Themes.  But that does
probably imply some more extensive rewriting.

Sincerely,

Luc.