GNU bug report logs -
#34027
27.0.50; disable-theme resets variables to their initial values
Previous Next
Reported by: Michael Albinus <michael.albinus <at> gmx.de>
Date: Thu, 10 Jan 2019 12:26:02 UTC
Severity: normal
Tags: fixed
Merged with 15687
Found in versions 24.3.50, 27.0.50
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #21 received at 34027 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Michael Albinus <michael.albinus <at> 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.
[Message part 2 (text/html, inline)]
[0001-Preserve-user-customizations-after-disabling-a-theme.patch (text/x-patch, attachment)]
This bug report was last modified 4 years and 290 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.