bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration

[Stefan Monnier]

> I'm sorry if I've misunderstood something after skimming this bug
> report, but I think the following recipe, starting from emacs -Q,
> illustrates the central issue:
>
>   ;; Sample custom theme touching user options and faces.
>   (with-temp-file (expand-file-name "foo-theme.el" custom-theme-directory)
>     (insert "\
>   (deftheme foo)
>   (custom-theme-set-variables 'foo '(text-quoting-style 'curved))
>   (custom-theme-set-faces 'foo '(default ((t :foreground \"white\"
>                                              :background \"black\"))))
>   (provide-theme 'foo)\n"))
>
>   ;; Make changes conflicting with theme `foo'.
>   (setq text-quoting-style 'grave)
>   (set-foreground-color "green")
>
>   ;; Load, enable, and disable theme `foo'.
>   (load-theme 'foo t)
>   (disable-theme 'foo)
>
> At the end of this, the value of text-quoting-style and the foreground
> of the default face are nil and "black", respectively.

Thanks.  Looks like a good recipe which finally describes the problem.

> Wouldn't it be less intrusive if they were reverted to the values they
> held before enabling foo-theme, namely 'grave and
> "green", respectively?

There is no question about that, yes: the code is clearly written with
the intention to reset those values to `grave` and "green".

I'm not very familiar with this code, but I know that there's some
attempt to make this work by saving the "externally modified" values
into a special theme called "changed" (as opposed to the changes made
via Custom which are saved in the special theme called "user").

So IIUC the above recipe shows that this special code either doesn't
properly save the settings to the "changed" theme, or they're not
properly used when recomputing the var's values in response to
`disable-theme`.


        Stefan