From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 15687@debbugs.gnu.org
Subject: bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration
Date: Tue, 26 Nov 2013 06:05:21 -0800 (PST) [thread overview]
Message-ID: <b5e27e50-c5ea-45fb-a32c-024a83999254@default> (raw)
In-Reply-To: <jwv8uwbrjyx.fsf-monnier+bug#15687@gnu.org>
> > You enable a custom theme. Then you disable it. The settings remain
> > those of the "disabled" custom theme. Your initial state is not
> > restored.
>
> I tried
>
> emacs -Q
> M-x custom-themes RET
> RET on the first theme to enable it
> RET again to disable it
>
> and the settings were apparently properly reset. Do you have a recipe
> that triggers the problem?
You skipped the first part:
You start out with Emacs in your preferred 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')
has been applied.
A demonstration that disabling a custom-theme can put you back to the
emacs -Q state is not too surprising. 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.
Of course, that state is not *automatically* recorded anywhere.
What's really missing, AFAICT, is the ability to take a snapshot of
the state, which can then be restored at any time. As the bug says:
AFAICT, there is no equivalent of such a snapshot with custom
themes, and it's not clear how to create one. But please prove me
wrong.
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.
See the full description of the bug. And see the treatment in
color-theme.el (not my library, BTW). There, you can take such a
snapshot at any time. And it serves, in effect, more or less as a
theme (a pseudo theme).
As the bug report says:
However, I do not see, for custom themes, what is an
important feature of `color-theme.el': the ability to take a snapshot
of the current settings (independent of how they were set, whether
via themes or not) as something that can function as a (pseudo)theme.
Compare these commands, which cycle among themes:
1. In doremi-cmd.el: `doremi-custom-themes+' vs `doremi-color-themes+'.
2. In icicles-cmd1.el: `icicle-custom-theme' vs `icicle-color-theme'.
From the doc string of `icicle-color-theme', this part about undoing:
If you use `C-g' during this command, the previous color-theme
snapshot is used to restore that color theme.
Remember too that you can use the pseudo-theme [Reset] to restore the
last theme: `M-x color-theme-select [Reset]'.
By default, each time you invoke this command, a snapshot is first
made of the current color theme (or current colors, if no theme is
used). Thus, by default, if you use `C-g', the colors restored are
those used before you changed themes using this command.
However, if you use a prefix arg, then this command takes no new
snapshot, unless no snapshot has ever been taken during this Emacs
session. This can be useful when experimenting, to restore not to
the state just before this command invocation, but to some previous
snapshot.
That part about the pseudo-them [Reset] is straight color-theme.el.
It has nothing to do with Icicles. See color-theme.el for info
about such a snapshot.
From the doc string of `icicle-custom-theme', by contrast:
You can use `C-g' to quit and cancel changes by the command. Note,
however, that some things might not be restored. `C-g' can only
disable any themes that you applied. It cannot restore other
customizations that enabling a theme might have overruled. This is
a limitation of Emacs custom themes: you can disable them, but you
cannot restore non-theme settings in effect before enabling a theme.
Color themes (and command `icicle-color-theme') do not have this
limitation.
From the doc string of `doremi-color-themes+':
You can use `C-g' to quit and cancel changes made so far.
Alternatively, after using `doremi-color-themes+' you can use
`color-theme-select' and choose pseudo-theme `[Reset]' - that does
the same thing. Note that in either case, some things might not
be restored.
From the doc string of `doremi-custom-themes+':
You can use `C-g' to quit and cancel changes made so far. Note,
however, that some things might not be restored. `C-g' can only
disable any themes that you applied. It cannot restore other
customizations that enabling a theme might have overruled.
----
An additional problem with custom themes, compared with color
themes, is that when multiple frames are present things become
extremely slow (maybe exponentially wrt the number of frames?
dunno).
This alone makes cycling among custom themes almost unusable
when there are multiple frames.
And this is the case even when, as is done for these cycling
commands, accumulation of custom themes is turned off. If, on
the other hand, accumulation is allowed (the normal case for
custom themes), then things really grind to a halt.
A guess would be that this might be because custom themes record
more information than color themes. But why this would make such
a difference, and why it might be related to the number of frames
in such a marked way, I have no idea.
If you want to see the difference, just try, say,
`doremi-custom-themes+' compared with `doremi-color-themes+',
with several frames open. You need only the files doremi.el and
doremi-cmd.el to try that. Both are on MELPA and on Emacs Wiki
(as are the Icicles files).
next prev parent reply other threads:[~2013-11-26 14:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-22 20:55 bug#15687: 24.3.50; custom themes: disabling does not restore initial configuration Drew Adams
2013-11-26 2:14 ` Stefan Monnier
2013-11-26 14:05 ` Drew Adams [this message]
2013-11-26 20:16 ` Stefan Monnier
2013-11-26 20:44 ` Drew Adams
2013-11-30 8:57 ` Glenn Morris
2013-11-30 17:10 ` Drew Adams
2014-11-05 3:48 ` Drew Adams
2018-06-14 19:53 ` Stefan Monnier
2013-11-26 14:08 ` Drew Adams
2013-11-26 18:47 ` William G. Gardella
2013-11-26 19:01 ` Drew Adams
2013-11-26 19:44 ` W. Greenhouse
2013-11-26 21:16 ` Drew Adams
2015-12-26 1:08 ` Lars Ingebrigtsen
2015-12-26 4:28 ` Drew Adams
2018-06-13 16:41 ` Basil L. Contovounesios
2018-06-14 20:03 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b5e27e50-c5ea-45fb-a32c-024a83999254@default \
--to=drew.adams@oracle.com \
--cc=15687@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.