Re: Bug, probably related to Custom Themes.

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

Richard Stallman wrote:

       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 careful checking my suspicions turned out to be completely
correct.  The current behavior (without my patch, which _partially_
fixes it) is as follows.

If you save a "setting" (to use the brand new terminology) and then
choose "Erase Customization" for the same setting, the no-themes
default gets restored for the current session and for future sessions
_until_ you choose "Erase Customization" for some _other_ setting.
After that, the no-themes default stays into effect for the remainder
of that session but for sessions started after that, the theme value is
restored.  This, of course, makes no sense whatsoever.  This is no
surprise.  Very few things in the current Themes code make any sense
whatsoever.

       I have the impression that the purpose of the:

       (custom-reset-variables
	'(bar nil))

       is to override foo's value and restore the no-themes default.

   I'm not sure what that ought to do.  Looking at the doc string, it is
   not clear that this case was intended to be used at all.

As I suspected, it does restore the no-themes default (I checked).

As I already said in an earlier message, we should get rid of the
current Themes code and replace it with something that makes sense.

Sincerely,

Luc.