deftheme, :inherit & overriding existing values

deftheme, :inherit & overriding existing values

[Dirk-Jan C. Binnema]

Hi all,

I've 'ported' the zenburn color theme
   https://github.com/djcb/elisp/blob/master/themes/zenburn-theme.el
to the new emacs 24+ color-theme system. I'm using the latest emacs 24 from
bzr.

Overall it works well if I start the theme from my .emacs startup, but it
works less well if I load a theme after some other packages. E.g., deftheme
before wanderlust works, but not the other way around.

Let's look at the 'describe-face' output, I've removed all the 'unspecified'
values.

Loading zenburn before Wanderlust (this works):
,----
| Face: wl-highlight-folder-unread-face (sample) (customize this face)
|        Inherit: (quote zenburn-red-3)
`----

Loading Wanderlust before zenburn (this does not work, i.e. the foreground
color will be 'gold', not 'zenburn-red-3'):

,----
| Face: wl-highlight-folder-unread-face (sample) (customize this face)
|     Foreground: gold
|     Inherit: (quote zenburn-red-3)
`----

Where zenburn-red-3 is defined as
       `(zenburn-red-3 ((t (:foreground ,zenburn-red-3))))

Apparently, :inherit does not really work as I expected...
       
Reloading the theme won't help -- but, what *does* help is visiting the theme
file and issuing M-x eval-buffer.

So, I'm not sure this is actually a *bug*, but the current behaviour seems
suboptimal anyhow. The equivalent of load-theme + eval-buffer gives the
expected result - maybe that should be the default behaviour of load-theme?

Best wishes,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

Re: deftheme, :inherit & overriding existing values

[Christoph Scholtes]

On 5/7/2011 3:17 AM, Dirk-Jan C. Binnema wrote:

> Overall it works well if I start the theme from my .emacs startup, but it
> works less well if I load a theme after some other packages. E.g., deftheme
> before wanderlust works, but not the other way around.

[snip]

> Apparently, :inherit does not really work as I expected...

I think this might be similar behavior to what I reported here:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8454

Christoph