[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Disabling custom themes

From: Daniel Colascione
Subject: Re: Disabling custom themes
Date: Wed, 13 Jun 2018 10:30:59 -0700
User-agent: SquirrelMail/1.4.23 [SVN]

> Drew Adams <address@hidden> writes:
>>> 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.
>> Thanks for reopening bug #15687.  And from your post there
>> I think you have understood.
>> To try to clarify -
>> I mean only that custom-theme enabling/disabling knows only
>> about (custom) themes.  It does not know about other user
>> customizations, so it cannot restore them when it is disabled.
>> What's missing is a function that captures the state of Emacs
>> (anything that a custom state might modify) before any custom
>> theme is applied, so that that state can be restored.
>> Then you could (as you can with color themes) invoke that
>> function to take a snapshot of your Emacs before "theming",
>> and you could use that snapshot to restore your Emacs pretty
>> much as it was before "theming".
> I would find this useful as well. I switch to `color-theme-dark-laptop'
> at night (which is very nice), and would like to be able to switch back
> to my own customized state the next morning.

Wouldn't it be nice if we'd modeled visual styles on CSS? Applying a theme
would just be enabling a stylesheet. The CSS model got things
fundamentally right in a lot of ways that I think every other theme
solution only approached.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]