GNU bug report logs - #15687
Disabling custom theme does not reset vars

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Tue, 22 Oct 2013 20:56:01 UTC

Severity: normal

Tags: fixed

Merged with 34027

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


View this message in rfc822 format

From: wgreenhouse <at> riseup.net (W. Greenhouse)
To: Drew Adams <drew.adams <at> oracle.com>
Cc: wgg2 <at> member.fsf.org, 15687 <at> debbugs.gnu.org
Subject: bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration
Date: Tue, 26 Nov 2013 19:44:48 +0000
Drew Adams <drew.adams <at> oracle.com> writes:

> Please read the bug report.  It includes the case where all themes
> that have ever been applied have since been disabled.  That does not
> restore all other customizations that were in effect before theming.
> That's all.

I read the bug report in detail.  Despite its length, it failed to
provide a minimal recipe for reproducing the bug.  Without it, I
essentially had to read your mind.  What I have been able to discover on
my own is that Custom themes do not prevent you from easily and
completely restoring faces altered with M-x customize.  I was able to do
so in my example.

> If you need a recipe, emacs -Q, load oneonone.el, then doremi.el and
> doremi-cmd.el.  Then cycle among themes, using `doremi-custom-themes+'.
> Use `C-g' to cancel.  The initial state is not restored.  Nothing
> close to it.  Not for any existing frames.

Since I was able to revert in the same frame completely without these
libraries, I think the problem lies not in the implementation of Custom
themes but rather the implementation for changing them in these
libraries.  To achieve a clean slate, `doremi-custom-themes' should do
exactly what `customize-themes' does: if
`custom-theme-allow-multiple-selections' is nil, `disable-theme' should
be called for every element in `custom-enabled-themes' before enabling a
new one.

> Sure, if you then create a new frame, things will look generally OK
> in that frame.  But the state of any existing frames has been altered
> and not restored.  Disabling a theme does not undo its effect wrt
> Emacs in general.  It simply disables one theme wrt other themes
> (including wrt all other themes).

Disabling a theme undoes its effect with respect to any setting made
through M-x customize.

> In addition, I see no way to take a snapshot of the current Emacs
> state as a theme, or even as a pseudo theme, to which one can revert.

(customize-create-theme) is roughly equivalent to
`color-theme-make-snapshot'.  It fills out a Custom theme using Emacs's
current state as a basis.

> This is something that is trivial with color themes - just call
> `color-theme-make-snapshot'.
>
> Try the same thing, but with command `doremi-color-themes+'.
> No problem.

As I alluded to in the last post, I think the problem lies in UI and
user expectations rather than underlying implementation.  I was never
able to get color-theme.el themes to undo themselves cleanly, because I
hadn't discovered `color-theme-make-snapshot' or your functions taking
advantage of it.

As far as I can determine from testing from emacs -Q, Custom themes
adhere to what (info "(emacs) Custom Themes") says they adhere to:

>    Any customizations that you make through the customization buffer
> take precedence over theme settings.  This lets you easily override
> individual theme settings that you disagree with.  If settings from two
> different themes overlap, the theme occurring earlier in
> `custom-enabled-themes' takes precedence.  In the customization buffer,
> if a setting has been changed from its default by a Custom theme, its
> `State' display shows `THEMED' instead of `STANDARD'.

Stuff set through Customize (whether before or after loading Custom
themes) survives enabling a theme, and those customizations will still
be there when any/all themes are disabled.  And in my own setup, which
is fairly complicated (an Emacs that's also subject to ~/.Xresources
theming as well as theming by elisp), frames do "return to normal" when
all themes are disabled.

I don't think Custom themes guarantee anything for settings made
otherwise than through M-x customize; for that case you could use
(customize-create-theme) similarly to how you'd use
(color-theme-make-snapshot) to make a point to reverse to.

--
Best,
WGG




This bug report was last modified 4 years and 260 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.