Disabling custom themes (was: Why is custom--inhibit-theme-enable not t by default?)

["Basil L. Contovounesios" <contovob@tcd.ie>]

Drew Adams <drew.adams@oracle.com> writes:

>> Doesn't the command disable-theme undo the application of a custom
>> theme?
>
> No.  Summary: There is no function that takes a snapshot
> of the Emacs state (even, e.g., as a custom theme) before
> applying any custom theme - which snapshot can then be used
> to restore that pre-theme state.
>
> You cannot undo the application of custom themes, to return
> to the state _before_ applying any theme.  You can only
> disable custom themes, not undo them to a non-theme state.
> You can swap one custom theme for another, but any
> non-theme state before applying a custom theme is lost.
>
> What's missing is the ability to put you back to anything
> close to the pre-theme state (i.e., as much as possible),
> whatever that customized state might have been. 
>
> https://www.emacswiki.org/emacs/CustomThemes#ComparedToColorThemes
>
> See bug #15687.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15687
>
> Recipe:
>
> 1. You start out with Emacs in your preferred (non-theme)
> customized state, a result perhaps of multiple option settings,
> frame parameter settings, face settings, etc.  For example,
> you have used `default-frame-alist' and customized some
> particular faces.
>
> No custom theme (except `user' - the default) has been applied yet.
>
> 2. You enable a custom theme.  Then you disable it.  The
> settings remain those of the "disabled" custom theme.  Your
> initial state is not restored.
>
> Disabling does not undo the effect upon Emacs of enabling -
> "disabling" is a misnomer.
>
> Enabling not only makes a theme current but also changes
> variable values, face settings, frame parameters etc., but
> _none of that is part of disabling_, except in so far as
> it affects or is affected by other custom themes.
>
> The ex-theme state of Emacs is ignored wrt both enabling
> and disabling.  There is no record of anything to restore.
>
> A more precise use case: As above, but you cycle among a
> set of custom themes.  You want C-g during the cycling to
> cancel (i.e., undo) all effects, restoring the initial
> state because you decided not to use any theme.
>
> With `color-theme.el' this is trivial to do: just take a
> (pseudotheme) snapshot before cycling, and then restore
> the snapshot upon C-g.
>
> There is no equivalent of such a snapshot with custom
> themes, and it's not clear how to create one.
>
> In particular, all of the custom-theme code requires a
> theme argument, which must be defined fully, including
> actually having been written to a theme file.  Hardly
> something that facilitates dynamic state recording and
> reverting.
>
> FWIW, I have code that uses (e.g., cycles among)
> either color themes or custom themes.  I don't "favor"
> one or the other.  Each kind has its advantages.
> Neither kind replaces the other.  A disadvantage of
> custom themes is that you cannot undo them.
>
> Not the end of the world, but for someone who wants to
> try out themes, starting from a customized Emacs (faces,
> frame parameters, etc.), it's not possible to simply
> cancel out (`C-g') of the trial and return to what you
> started with.
>
> You can of course quit Emacs and start a new session,
> to get back your initial, customized state.  But you
> can't simply _undo_ the effect of applying a custom theme.

Sorry, I'm not sure I completely understand what you mean (for example
w.r.t. "initial state" and "settings of the 'disabled' custom theme"),
but I've posted a recipe with what I think you're getting at to
bug#15687, where I think any further discussion of the effects of theme
disabling can be continued.

Either way, thanks for the explanation and background.

-- 
Basil