Re: Disabling custom themes

["Daniel Colascione" <dancol@dancol.org>]

> Drew Adams <drew.adams@oracle.com> 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.