[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Disabling custom themes (was: Why is custom--inhibit-theme-enable not t
From: |
Basil L. Contovounesios |
Subject: |
Disabling custom themes (was: Why is custom--inhibit-theme-enable not t by default?) |
Date: |
Wed, 13 Jun 2018 19:55:35 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Drew Adams <address@hidden> 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
- Why is custom--inhibit-theme-enable not t by default?, dancol, 2018/06/12
- Re: Why is custom--inhibit-theme-enable not t by default?, Eli Zaretskii, 2018/06/12
- Re: Why is custom--inhibit-theme-enable not t by default?, dancol, 2018/06/12
- Re: Why is custom--inhibit-theme-enable not t by default?, Eli Zaretskii, 2018/06/12
- RE: Why is custom--inhibit-theme-enable not t by default?, Drew Adams, 2018/06/12
- Re: Why is custom--inhibit-theme-enable not t by default?, Basil L. Contovounesios, 2018/06/13
- RE: Why is custom--inhibit-theme-enable not t by default?, Drew Adams, 2018/06/13
- Disabling custom themes (was: Why is custom--inhibit-theme-enable not t by default?),
Basil L. Contovounesios <=
- RE: Disabling custom themes (was: Why is custom--inhibit-theme-enable not t by default?), Drew Adams, 2018/06/13
- Re: Disabling custom themes, Eric Abrahamsen, 2018/06/13
- Re: Disabling custom themes, Daniel Colascione, 2018/06/13
- Re: Why is custom--inhibit-theme-enable not t by default?, Richard Stallman, 2018/06/13
- Re: Why is custom--inhibit-theme-enable not t by default?, Stefan Monnier, 2018/06/13
- RE: Why is custom--inhibit-theme-enable not t by default?, Drew Adams, 2018/06/14
- Re: Why is custom--inhibit-theme-enable not t by default?, Stefan Monnier, 2018/06/14
- RE: Why is custom--inhibit-theme-enable not t by default?, Drew Adams, 2018/06/14
- Re: Why is custom--inhibit-theme-enable not t by default?, Stefan Monnier, 2018/06/14
- Re: Why is custom--inhibit-theme-enable not t by default?, Basil L. Contovounesios, 2018/06/14