Michael Albinus <
michael.albinus@gmx.de> writes:
> Scenario:
>
> - Declare a variable (either defvar or defcustom)
> - Change the initial value to something else
> - Enable a theme, which changes the value to something different, again
> - Disable the theme
>
> I would expect that the variable has been reset to the value prior
> enabling the theme. But it is reset to the initial value.
>
There is code in custom-push-theme that attempts to handle this case,
but it was being skipped because custom didn't think it should apply the
settings of the theme (and at the same time, preserve priors
customizations).
That is controlled by the variable custom--inhibit-theme-enable, and
we should bind it to nil in enable-theme, because we are definitely
enabling it. Once we do that, it is just a matter of using
custom-push-theme to handle the case like it's supposed to.
My patch does that, and introduces an extra check in custom-push-theme,
because while testing I found another instance of Bug#28904. The rest
this patch does is changing the test because of the comments I made in
another post to this bug, and we now can expect the test to pass.
0001-Preserve-user-customizations-after-disabling-a-theme.patch