Re: color-theme.el

[Alex Schroeder]

Richard Stallman <address@hidden> writes:

>     Integrate real themes, a.la. Jan Vroonhofs work.
>
> What is better about that?  Would it provide more features (which),
> work more reliably, be less code, or what?

There are two main advantages.

Here is how it basically works: A setting is tagged as coming from a
theme.  The settings currently loaded from .emacs or similar would be
tagged as coming from the "user" theme, and the standard values would
be tagged as coming from the "standard" theme.  Authors could now
write additional themes.  Anytime a variable is set via custom or
themes, this is recorded.

Advantage 1: When you customize variabes that where set via a theme,
the custom buffer could offer more information.  I faintly remember
that it currently just says that it was set using a theme.  But it
could name the theme, or even all the installed themes that tried
setting the variable (and the current value would be from the last
theme installed).

Advantage 2: When you undo a theme, custom can set the variable to
something else than the standard value or the saved (user) value.  It
can set it to the second-to-last installed theme, for example.

Or, putting it another way, assume a variable foo with a default value
of A.  The user customizes it to B and saves this.  In his .emacs, the
user then loads two themes, "theme 1" and "theme 2".  The first sets
foo to C, the second sets foo to D.

The value of foo is now D.  When "theme 2" is undone, the value will
be C.

Currently (and if we followed my much simple suggestions), the same
situation would result in a different end:  When Emacs starts, foo is
eventually set to D.  If you want to go back to the second-to-last
value (C), you might want to undo "theme 2".  But there is no way to
undo "theme 2", except to install "theme 1" again.  Custom would only
know the current value (D), the saved value (B) and the standard value
(A).

My position is that this is no great loss.

Alex.