GNU bug report logs - #8454
24.0; Emacs does not apply additional custom faces from theme

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8454 in the body.
You can then email your comments to 8454 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0; Emacs does not apply additional custom faces from theme
Date: Fri, 08 Apr 2011 21:51:05 -0600

I downloaded a custom theme from elpa
(http://elpa.gnu.org/themes/2lzrreXz) and added some faces at the bottom:

 ; erc
 '(erc-default-face ((t (:inherit default))))
 '(erc-my-nick-face ((t (:inherit font-lock-variable-name-face))))
 '(erc-current-nick-face ((t (:inherit font-lock-string-face))))
 '(erc-input-face ((t (:inherit font-lock-type-face))))
 '(erc-keyword-face ((t (:inherit font-lock-keyword-face))))
 '(erc-timestamp-face ((t (:inherit font-lock-builtin-face))))
 '(erc-notice-face ((t (:inherit font-lock-comment-face))))

These faces inherit their values from the faces set in the custom theme.

The problem is, none of the custom faces for erc are actually
applied. Emacs still has the original erc faces.


In GNU Emacs 24.0.50 (i386-mingw-nt6.1.7600)
 of 2011-04-06 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7600
configured using `configure --with-gcc (4.5) --cflags -IC:/Progra~2/GnuWin32/include -ID:/devel/emacs/libXpm-3.5.8/include -ID:/devel/emacs/libXpm-3.5.8/src'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  erc-list-mode: t
  erc-menu-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-netsplit-mode: t
  paredit-mode: t
  erc-autojoin-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-pcomplete-mode: t
  erc-stamp-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  recentf-mode: t
  desktop-save-mode: t
  autopair-mode: t
  autopair-global-mode: t
  ido-everywhere: t
  yas/global-mode: t
  yas/minor-mode: t
  global-auto-revert-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t

Recent input:
C-e C-a C-x C-f p l u g <return> t h e <return> C-s 
<return> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-p C-k C-k C-k 
C-x C-s C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-x RET 
C-g C-x C-f M-p M-p <backspace> e r c <return> e r 
c . e l <return> C-v C-x RET l o a d <backspace> <backspace> 
<backspace> <backspace> e v a l - v u <backspace> <backspace> 
b u f f e r <return> C-h v e r c - d e f <tab> f <tab> 
<tab> <tab> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> a <tab> <backspace> f a <tab> 
<tab> <tab> <tab> C-g M-g M-g 1 1 3 9 <return> C-h 
v e r c - h e a d e r - l i n e <tab> <tab> <tab> C-g 
C-h v e r c - i n p u t - f a <tab> <tab> <tab> <tab> 
C-g C-x k <return> C-n C-n C-n C-n C-n C-n C-SPC C-SPC 
C-n C-n C-n C-n C-n C-n C-n C-n M-w C-x m c s u t o 
<backspace> <backspace> <backspace> <backspace> u s 
t o m - t e <backspace> h e m e SPC n o t SPC <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> e m a c s <backspace> <backspace> <backspace> 
<backspace> <backspace> C-x k <return> y <down-mouse-1> 
<mouse-1> C-x m r e p o r t C-x k <return> y C-x RET 
r e p o r t <tab> <return>

Recent messages:
Loading vc-bzr...done
Disabling `erc-pcomplete'
Quit
Mark set
Making completion list...
Quit [2 times]
Mark set
Mark activated
Auto-saving...done
Buffer *unsent mail* modified; kill anyway? (y or n)  y [2 times]

Load-path shadows:
c:/Users/Christoph/AppData/Roaming/.emacs.d/plugins/python hides d:/devel/emacs/emacs-bzr/trunk_readonly/lisp/progmodes/python

Features:
(shadow sort mail-extr emacsbug url-util url-parse url-vars gnus-cite
gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime dig
mailcap vc-bzr tramp warnings tramp-compat auth-source eieio byte-opt
bytecomp byte-compile cconv password-cache tramp-loaddefs vc-hg
network-stream starttls tls erc-menu erc-ring comint ring erc-networks
erc-button erc-fill erc-netsplit paredit my-zenburn-theme sha1 hex-util
erc-join erc-track erc-match erc-pcomplete pcomplete erc-stamp
erc-goodies erc erc-backend erc-compat thingatpt bookmark+ dired-x dired
bookmark+-1 nnir gnus-sum macroexp nnoo gnus-group gnus-undo nnmail
mail-source gnus-start gnus-spec gnus-int gnus-range message format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus
gnus-ems nnheader gnus-util time-date mail-utils mm-util mail-prsvr
bookmark+-bmu help-mode view bookmark+-lit pp+ bookmark+-mac bookmark pp
recentf tree-widget wid-edit midnight desktop ibuffer uniquify autopair
cc-styles cc-align cc-engine cc-vars cc-defs browse-kill-ring+
browse-kill-ring second-sel ido yasnippet dropdown-list easymenu assoc
org-install server advice advice-preload autorevert delsel tooltip
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp
w32-win w32-vars tool-bar dnd fontset image fringe edmacro kmacro
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock regexp-opt syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic ccl
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
help-macro simple derived abbrev minibuffer easy-mmode loaddefs button
faces cus-face files help-fns text-properties overlay md5 base64 format
env cl code-pages mule cus-start custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)

Message #8 received at 8454 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: 8454 <at> debbugs.gnu.org, "Dirk-Jan C. Binnema" <djcb.bulk <at> gmail.com>
Subject: Re: deftheme, :inherit & overriding existing values
Date: Sun, 08 May 2011 15:19:56 -0400

Christoph Scholtes <cschol2112 <at> googlemail.com> writes:

> 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

I'm afraid both bug reports are too vague for me to figure out exactly
what is supposed to be going wrong.  Could someone provide a precise,
step-by-step recipe for reproducing the problem?

In the case of Christoph's report (Bug#8454), the statement "none of the
custom faces for erc are actually applied" isn't specific, and when I
tried to reproduce this, the buffer produced by M-x erc RET RET RET
seems to display erc-default-face using the Zenburn default.  A more
precise description of the problem is needed.

As for Dirk-Jan's report, it is very inconvenient to reference external
packages like Wanderlust.  Please provide a recipe using something in
Emacs itself.

Message #11 received at 8454 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: 8454 <at> debbugs.gnu.org, "Dirk-Jan C. Binnema" <djcb.bulk <at> gmail.com>
Subject: Re: bug#8454: deftheme, :inherit & overriding existing values
Date: Sun, 08 May 2011 16:14:53 -0400

Chong Yidong <cyd <at> stupidchicken.com> writes:

> I'm afraid both bug reports are too vague for me to figure out exactly
> what is supposed to be going wrong.  Could someone provide a precise,
> step-by-step recipe for reproducing the problem?

OK, I found a bug in the case where defface is called after loading a
theme with settings for that face.  The defface settings were not being
applied; I've checked a fix into the trunk.  However, I'm not sure this
is the issue you are talking about, since this bug was not specific to
the :inherit property.  Could you check if your problem is fixed?

One possible source of confusion, which may apply to Dirk-Jan's report,
is that :inherit only tells Emacs to consult the parent face if a face
attribute is unspecified.  If the attribute is specified, it overrides
the inheritance.  So if your Custom theme want to "cancel out", say, any
existing foreground attribute setting, you need something like

 '(froob ((t (:foreground unspecified :inherit parent-face))))

Message #14 received at 8454 <at> debbugs.gnu.org (full text, mbox):

From: Dirk-Jan C. Binnema <djcb <at> djcbsoftware.nl>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Christoph Scholtes <cschol2112 <at> googlemail.com>, 8454 <at> debbugs.gnu.org
Subject: Re: bug#8454: deftheme, :inherit & overriding existing values
Date: Mon, 09 May 2011 23:41:34 +0300

Hi,

>>>>> On Sun, 08 May 2011 16:14:53 -0400, Chong Yidong ("CYD") wrote:

  CYD> Chong Yidong <cyd <at> stupidchicken.com> writes:
  >> I'm afraid both bug reports are too vague for me to figure out exactly
  >> what is supposed to be going wrong.  Could someone provide a precise,
  >> step-by-step recipe for reproducing the problem?

Sorry about the 'vagueness' - but glad you found it out anyhow.
  
  CYD> OK, I found a bug in the case where defface is called after loading a
  CYD> theme with settings for that face.  The defface settings were not being
  CYD> applied; I've checked a fix into the trunk.  However, I'm not sure this
  CYD> is the issue you are talking about, since this bug was not specific to
  CYD> the :inherit property.  Could you check if your problem is fixed?

No, it does solve the problem, but I guess below confirms my suspicion..
  
  CYD> One possible source of confusion, which may apply to Dirk-Jan's report,
  CYD> is that :inherit only tells Emacs to consult the parent face if a face
  CYD> attribute is unspecified.  If the attribute is specified, it overrides
  CYD> the inheritance.  So if your Custom theme want to "cancel out", say, any
  CYD> existing foreground attribute setting, you need something like

  CYD>  '(froob ((t (:foreground unspecified :inherit parent-face))))

Ok, yes that is what happens. I guess this could work, but in practice it
makes :inherit rather suboptimal -- imagine switching from one theme to
another, you'd have to explicitly cancel out every attribute the other theme
may have set.

Best wishes,
Dirk.

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

Message #17 received at 8454 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 8454 <at> debbugs.gnu.org, "Dirk-Jan C. Binnema" <djcb.bulk <at> gmail.com>
Subject: Re: bug#8454: deftheme, :inherit & overriding existing values
Date: Mon, 09 May 2011 21:18:25 -0600

On 5/8/2011 2:14 PM, Chong Yidong wrote:

> OK, I found a bug in the case where defface is called after loading a
> theme with settings for that face.  The defface settings were not being
> applied; I've checked a fix into the trunk.  However, I'm not sure this
> is the issue you are talking about, since this bug was not specific to
> the :inherit property.  Could you check if your problem is fixed?
>
> One possible source of confusion, which may apply to Dirk-Jan's report,
> is that :inherit only tells Emacs to consult the parent face if a face
> attribute is unspecified.  If the attribute is specified, it overrides
> the inheritance.  So if your Custom theme want to "cancel out", say, any
> existing foreground attribute setting, you need something like
>
>   '(froob ((t (:foreground unspecified :inherit parent-face))))

This did not fix it for me.

I think Dirk-Jan and I have the same issue, though, which is the 
behavior of :inherit.

One example from my custom theme:

 '(erc-default-face ((t (:inherit default))))

This is supposed to inherit from

 '(default ((t (:background "#3f3f3f" :foreground "#dcdccc"))))

but it does not work.

This is probably related to what you describe above, but I don't really 
understand it. foregound in erc-default-face is unspecified, right? 
Should the inherit get the attributes from default or not?

I figured out a way to make my custom theme work, though. Loading it 
through customize does not work, but if I open the theme file and eval 
the buffer, it works and erc shows the my custom faces. Maybe this helps 
to troubleshoot the problem?

Christoph

Message #20 received at 8454 <at> debbugs.gnu.org (full text, mbox):

From: Dirk-Jan C. Binnema <djcb <at> djcbsoftware.nl>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: 8454 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>
Subject: Re: bug#8454: deftheme, :inherit & overriding existing values
Date: Fri, 13 May 2011 07:50:05 +0300

Hi,

>>>>> On Mon, 09 May 2011 21:18:25 -0600, Christoph Scholtes ("CS") wrote:

  CS> On 5/8/2011 2:14 PM, Chong Yidong wrote:
  >> OK, I found a bug in the case where defface is called after loading a
  >> theme with settings for that face.  The defface settings were not being
  >> applied; I've checked a fix into the trunk.  However, I'm not sure this
  >> is the issue you are talking about, since this bug was not specific to
  >> the :inherit property.  Could you check if your problem is fixed?
  >> 
  >> One possible source of confusion, which may apply to Dirk-Jan's report,
  >> is that :inherit only tells Emacs to consult the parent face if a face
  >> attribute is unspecified.  If the attribute is specified, it overrides
  >> the inheritance.  So if your Custom theme want to "cancel out", say, any
  >> existing foreground attribute setting, you need something like
  >> 
  >> '(froob ((t (:foreground unspecified :inherit parent-face))))

  CS> This did not fix it for me.

  CS> I think Dirk-Jan and I have the same issue, though, which is the
  CS> behavior of :inherit.

Yes -- in fact, before this change, the theme would look as expected if I
loaded it before - say - Wanderlust. However, with this change, that does not
work either anymore.
  
  CS> One example from my custom theme:

  CS>  '(erc-default-face ((t (:inherit default))))

  CS> This is supposed to inherit from

  CS>  '(default ((t (:background "#3f3f3f" :foreground "#dcdccc"))))

  CS> but it does not work.

  CS> This is probably related to what you describe above, but I don't
  CS> really understand it. foregound in erc-default-face is unspecified,
  CS> right? Should the inherit get the attributes from default or not?

  CS> I figured out a way to make my custom theme work, though. Loading it
  CS> through customize does not work, but if I open the theme file and eval
  CS> the buffer, it works and erc shows the my custom faces. Maybe this
  CS> helps to troubleshoot the problem?

Yes, indeed, that is what I do too now:
  
(defun zenburn()
  (interactive)
  (load-theme 'zenburn)
  (load-library "~/.emacs.d/elisp/themes/zenburn-theme.el"))


In general, it might make sense to first go back to 'factory settings' before
changing the theme, as it's quite unlikely that theme2 always overrides
everything from theme1 -- e.g. zenburn redefines hundreds of faces.
  
Best wishes,
Dirk.

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

Message #23 received at 8454 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: 8454 <at> debbugs.gnu.org
Subject: I can't reproduce this
Date: Sun, 23 Oct 2011 12:58:48 -0400

[Message part 1 (text/plain, inline)]

In emacs 23.3, I tried to build a minimal test case that would exhibit
some of the problems cited here, and failed.  What I wrote is below, and
loading it with `emacs -Q -l test.el' seems to produce the expected
results.  If there *is* a real problem, it seems to me, some simple
variation on this code should show it.

[test.el (text/emacs-lisp, inline)]

;; define a couple of faces to be used in the theme
(defface face1
    '((t :background "pink"))
    "first test face")
(defface face2
    '((t :background "yellow"))
    "second test face")

;; simulate (load 'theme1)
(deftheme theme1
  "1st test theme")
(custom-theme-set-faces
 'theme1
 '(face2 ((t (:slant italic :inherit (face1)))))
 '(face3 ((t (:background "yellow"))))
 '(face4 ((t (:inherit (face3))))))
(provide-theme 'theme1)
;; done loading theme1

;; define some more faces used in the theme
(defface face3
    '((t :background "pink"))
    "3rd test face")
(defface face4
    '((t :slant italic))
    "4th test face")

;; inspect the faces
(setq inhibit-startup-screen t)
(customize-apropos-faces "^face[0-9]")

Message #26 received at 8454 <at> debbugs.gnu.org (full text, mbox):

From: Chris Hanson <cph <at> chris-hanson.org>
To: 8454 <at> debbugs.gnu.org
Subject: Themes can't work right due to design
Date: Sun, 4 Dec 2011 22:54:09 -0800

I've just started using Emacs 24 (pretest 3), and have run into
problems getting Zenburn to work right.  Previously in Emacs 23 I used
the color-theme package and a zenburn theme designed for that package.
 It needed a little tweaking but is otherwise fine.

In Emacs 24, using custom-theme and a similar zenburn theme designed
for that package, I'm having trouble getting the theme to work
properly.

I believe there are two underlying problems causing this behavior.

The first is that :inherit isn't very useful as a way to say "make the
current face like the specified one".  Because color-theme clobbers
face-defface-spec, it effectively erases any previous face settings,
so that the theme settings are self-contained.  There is no equivalent
way to do this with custom-theme, which has led me to write things
like `(font-lock-type-face ,zenburn-primary-3) rather than
`(font-lock-type-face ((t (:inherit zenburn-primary-3)))) .  This
works but is somewhat unsatisfying.

The second is that a face attribute that's explicitly set can't be
overridden by a custom theme, for reasons I'm not completely clear on.
 For example, "cc-fonts.el" contains (set-face-foreground
'c-annotation-face "blue") and the theme doesn't seem to be able to
override this foreground under any circumstances, even with an
explicitly set :foreground attribute.  This just seems like a bug.

I'll probably just go back to using color-theme, since at least it
works.  I was hoping that Emacs 24 would allow me get good behavior
without it, but alas...

Let me know if you need help debugging anything.

Message #29 received at 8454 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chris Hanson'" <cph <at> chris-hanson.org>, <8454 <at> debbugs.gnu.org>
Subject: RE: bug#8454: Themes can't work right due to design
Date: Mon, 5 Dec 2011 09:52:10 -0800

> :inherit isn't very useful as a way to say "make the
> current face like the specified one".

+1.

It's a sledge hammer, and it is way overused (& increasingly so).
(Just one opinion.)

See also 
http://lists.gnu.org/archive/html/emacs-devel/2011-02/msg00067.html

Message #32 received at 8454 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Chris Hanson <cph <at> chris-hanson.org>
Cc: 8454 <at> debbugs.gnu.org
Subject: Re: bug#8454: Themes can't work right due to design
Date: Mon, 05 Dec 2011 14:03:32 -0500

> The first is that :inherit isn't very useful as a way to say "make the
> current face like the specified one".  Because color-theme clobbers
> face-defface-spec, it effectively erases any previous face settings,
> so that the theme settings are self-contained.  There is no equivalent
> way to do this with custom-theme, which has led me to write things
> like `(font-lock-type-face ,zenburn-primary-3) rather than
> `(font-lock-type-face ((t (:inherit zenburn-primary-3)))) .  This
> works but is somewhat unsatisfying.

I don't really understand the problem here, probably because I'm not
sufficiently versed in themes, but just in case, you may want to give
a more specific example of what behavior you're trying to get, what you
tried (presumably something like ((t (:inherit foo)))) and what you
don't like about the resulting behavior.

> The second is that a face attribute that's explicitly set can't be
> overridden by a custom theme, for reasons I'm not completely clear on.

That's the way the interaction between custom settings and Lisp settings
are defined, because it seems like the only "sane" way to handle it.

>  For example, "cc-fonts.el" contains (set-face-foreground
> 'c-annotation-face "blue")

Probably something that should be fixed.


        Stefan

Message #35 received at 8454 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 8454 <at> debbugs.gnu.org, Chris Hanson <cph <at> chris-hanson.org>
Subject: Re: bug#8454: Themes can't work right due to design
Date: Tue, 06 Dec 2011 10:22:46 +0800

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

>>  For example, "cc-fonts.el" contains (set-face-foreground
>> 'c-annotation-face "blue")
>
> Probably something that should be fixed.

I've committed a fix for this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.