bug#9982: M-x load-theme does not change background color

bug#9982: M-x load-theme does not change background color

[Brendan Miller]

When loading emacs color themes with M-x load-theme, the background
color is never set to anything other than white. Tested with manoj-dark,
which is explicitly documented as having a black background.

Other aspects of the color theme seem to apply correctly.

I'm running on linux with gtk emacs 24 built off of the git repository.

bug#9982: M-x load-theme does not change background color

[Glenn Morris]

Brendan Miller wrote:

> When loading emacs color themes with M-x load-theme, the background
> color is never set to anything other than white. Tested with manoj-dark,
> which is explicitly documented as having a black background.

Works for me with both Lucid and GTK builds of the current trunk.

emacs -Q                            ;  background is white
M-x load-theme RET manoj-dark RET   ;  background is black

Does it work in emacs -Q for you?
Do you have a system theme that imposes a colour?

The information that M-x report-emacs-bug provides might be useful.

bug#9982: M-x load-theme does not change background color

[Brendan Miller]

I tested originally with emacs -Q.

I originally found the problem in an XFCE environment. I tried it out
on Gnome, and it seemed to work fine. So it may be related to some
kind of system theme.

Another thought is that my XFCE environment has GTK3 libs installed,
whereas the gnome environment has only GTK2 libs, so it might be
related to that. Is there a way to check whether emacs is linking
against GTK2 or GTK3?

On Mon, Nov 7, 2011 at 9:46 AM, Glenn Morris <rgm@gnu.org> wrote:
> Brendan Miller wrote:
>
>> When loading emacs color themes with M-x load-theme, the background
>> color is never set to anything other than white. Tested with manoj-dark,
>> which is explicitly documented as having a black background.
>
> Works for me with both Lucid and GTK builds of the current trunk.
>
> emacs -Q                            ;  background is white
> M-x load-theme RET manoj-dark RET   ;  background is black
>
> Does it work in emacs -Q for you?
> Do you have a system theme that imposes a colour?
>
> The information that M-x report-emacs-bug provides might be useful.
>

bug#9982: M-x load-theme does not change background color

[Glenn Morris]

Brendan Miller wrote:

> Is there a way to check whether emacs is linking against GTK2 or GTK3?

I wrote:

>> The information that M-x report-emacs-bug provides might be useful.

bug#9982: M-x load-theme does not change background color

[Stefan Monnier]

> I tested originally with emacs -Q.
> I originally found the problem in an XFCE environment. I tried it out
> on Gnome, and it seemed to work fine. So it may be related to some
> kind of system theme.

Note that a system theme should take lower precedence than a color theme
loaded via M-x load-theme.  So even if this background color comes from
a system theme, we still have a bug.
OTOH if this background color comes from a setting of your (e.g. via
customize), then it's normal since the user theme takes precedence over
all other themes.


        Stefan

bug#9982: M-x load-theme does not change background color

[Brendan Miller]

I think I've narrowed down the bug somewhat. There is something wrong
with the (set-background-color "color-here") function. This is a
regression from emacs 23.3 where that function works fine on the same
machine.

I tried (set-background-color "black") and this function seems very
erratic. It will succeed part way (not for all lines on buffer), but
then fail to set the color back to white on the next call. Assuming
that load-theme uses this function, I think this is probably where the
bug is.

I tried launching emacs with emacs --background-color=black, and that
succeeds in making the background color black.

This is run under emacs -Q. I tried doing a git pull and recompiling
everything just to be sure it's not already fixed.

I'm running under Arch Linux on XFCE. I followed the output of the
./configure script, and it seems I am building against GTK2 libraries.

I'll experiment a bit and see if I can narrow down the problem further.

I'm adding the diagnostic information from report-emacs-bug below. I
was having trouble sending via report-emacs-bug method directly, as it
didn't seem to like my smtp server.

In GNU Emacs 24.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.24.7)
 of 2011-11-07 on arch
Windowing system distributor `The X.Org Foundation', version 11.0.11101902
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: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-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
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x l o a d - t h e <tab> <return> m a n o <tab> <return>
M-x r e p o r t - b u g <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message format-spec rfc822 mml easymenu
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug manoj-dark-theme time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock 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 indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

bug#9982: M-x load-theme does not change background color

[Eli Zaretskii]

> Date: Mon, 7 Nov 2011 21:51:33 -0800
> From: Brendan Miller <catphive@catphive.net>
> Cc: 9982@debbugs.gnu.org
> 
> I think I've narrowed down the bug somewhat. There is something wrong
> with the (set-background-color "color-here") function. This is a
> regression from emacs 23.3 where that function works fine on the same
> machine.
> 
> I tried (set-background-color "black") and this function seems very
> erratic. It will succeed part way (not for all lines on buffer), but
> then fail to set the color back to white on the next call. Assuming
> that load-theme uses this function, I think this is probably where the
> bug is.

Can you show a screenshot with such erratic results?

set-background-color only sets the background color of the default
face, so if the buffer shows portions of the text with faces other
than different that specify the background color, set-background-color
will not change the background for those portions of text.

bug#9982: M-x load-theme does not change background color

[Brendan Miller]

Here's a screenshot of what (set-background-color "black") does the
first time I execute it. Toggling between white and black a few times
can get it into other states.

http://www.zimagez.com/zimage/screenshot-11072011-113329pm.php

bug#9982: M-x load-theme does not change background color

[Eli Zaretskii]

> Date: Mon, 7 Nov 2011 23:38:51 -0800
> From: Brendan Miller <catphive@catphive.net>
> Cc: monnier@iro.umontreal.ca, 9982@debbugs.gnu.org
> 
> Here's a screenshot of what (set-background-color "black") does the
> first time I execute it. Toggling between white and black a few times
> can get it into other states.
> 
> http://www.zimagez.com/zimage/screenshot-11072011-113329pm.php

Does "M-x redraw-display RET" fixes such a "partial" display of the
background?

bug#9982: M-x load-theme does not change background color

[Brendan Miller]

On Tue, Nov 8, 2011 at 12:24 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> Does "M-x redraw-display RET" fixes such a "partial" display of the
> background?
>
>

No. That command causes no visible change.

bug#9982: M-x load-theme does not change background color

[Eli Zaretskii]

> Date: Tue, 8 Nov 2011 00:34:56 -0800
> From: Brendan Miller <catphive@catphive.net>
> Cc: monnier@iro.umontreal.ca, 9982@debbugs.gnu.org
> 
> On Tue, Nov 8, 2011 at 12:24 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Does "M-x redraw-display RET" fixes such a "partial" display of the
> > background?
> >
> 
> No. That command causes no visible change.

This means Emacs "thinks" it drew the entire window already.

What about minimizing and then maximizing the frame -- does that fix
the display?

bug#9982: M-x load-theme does not change background color

[Jan Djärv]

Hello.

8 nov 2011 kl. 08:38 skrev Brendan Miller:

> Here's a screenshot of what (set-background-color "black") does the
> first time I execute it. Toggling between white and black a few times
> can get it into other states.
> 
> http://www.zimagez.com/zimage/screenshot-11072011-113329pm.php
> 
> 

Can you reproduce this with the latest trunk?
There was a change that probably fixes this.

Thanks,

	Jan D.

bug#9982: M-x load-theme does not change background color

[Jan Djärv]

Hello.


8 nov 2011 kl. 08:38 skrev Brendan Miller:

> Here's a screenshot of what (set-background-color "black") does the
> first time I execute it. Toggling between white and black a few times
> can get it into other states.
> 
> http://www.zimagez.com/zimage/screenshot-11072011-113329pm.php
> 

Upon further investigation, this is not a Gtk+ problem, it happend for lucid also.
But just for the first set-background-color call.

There seems to be some error in the face/frame interaction.  This is what happens for me:

(set-background-color "black")
  (set-frame-parameter "background" "black")
  ...
   x_set_background_color ("black")
     update_face_from_frame_parameter (f, Qbackground_color, arg);
     ...
       (frame-set-background-mode)
       ...
         (face-spec-recalc)
         ...
          (set-frame-parameter "background" "white")

So the background is first black and then white again.  It seems that redisplay uses the GC with background black, but as the window background is white, those parts not redrawn (i.e. without text) are white.

I don't know why this is only seen with XFCE and just for the first set-background-color call.

	Jan D.

bug#9982: Theme faces wrongly applied after background changes.

[Jan Djärv]

Hello.

I investigated further.
In the face-spec-recalc one does this:

(let ((theme-faces (reverse (get face-sym 'theme-face))))
      (dolist (spec theme-faces)
	(face-spec-set-2 face frame (cadr spec))))

The problem is that for the default face we have set the background to black, but the theme variant of default is still white, so the background is painted white.
Then the redisplay happens, and the parts with text have black background, but other parts still have white.  I guess this only happens in XFCE due to a race condition.

The complete theme face is:

((user ((t (:inherit nil :stipple nil :background "white" :foreground "black" :inverse-video nil :box nil :strike-through nil :overline nil :underline nil :slant normal :weight normal :height 98 :width normal :foundry "unknown" :family "DejaVu Sans Mono")))))

I don't know where this theme face comes from, I haven' set any theme.  But it still gets applied after the background color has been changed.

Can someone in that knows about faces and themes check this?

Thanks,

	Jan D.

11 dec 2011 kl. 14:17 skrev Jan Djärv:

> Hello.
> 
> 
> 8 nov 2011 kl. 08:38 skrev Brendan Miller:
> 
>> Here's a screenshot of what (set-background-color "black") does the
>> first time I execute it. Toggling between white and black a few times
>> can get it into other states.
>> 
>> http://www.zimagez.com/zimage/screenshot-11072011-113329pm.php
>> 
> 
> Upon further investigation, this is not a Gtk+ problem, it happend for lucid also.
> But just for the first set-background-color call.
> 
> There seems to be some error in the face/frame interaction.  This is what happens for me:
> 
> (set-background-color "black")
>  (set-frame-parameter "background" "black")
>  ...
>   x_set_background_color ("black")
>     update_face_from_frame_parameter (f, Qbackground_color, arg);
>     ...
>       (frame-set-background-mode)
>       ...
>         (face-spec-recalc)
>         ...
>          (set-frame-parameter "background" "white")
> 
> So the background is first black and then white again.  It seems that redisplay uses the GC with background black, but as the window background is white, those parts not redrawn (i.e. without text) are white.
> 
> I don't know why this is only seen with XFCE and just for the first set-background-color call.
> 
> 	Jan D.
> 
> 

bug#9982: Theme faces wrongly applied after background changes.

[Chong Yidong]

> I investigated further.
> In the face-spec-recalc one does this:
>
> (let ((theme-faces (reverse (get face-sym 'theme-face))))
>       (dolist (spec theme-faces)
> 	(face-spec-set-2 face frame (cadr spec))))
>
> The problem is that for the default face we have set the background to
> black, but the theme variant of default is still white, so the
> background is painted white.

I installed xfce4 and can now reproduce the bug.  The problem is the
existence of the `theme-face' property for `default', which is present
at startup even with emacs -Q.  I don't know where this is coming from
either, but it rings a dim bell---I'll try to investigate further.

bug#9982: Theme faces wrongly applied after background changes.

[Chong Yidong]

Chong Yidong <cyd@gnu.org> writes:

> I installed xfce4 and can now reproduce the bug.  The problem is the
> existence of the `theme-face' property for `default', which is present
> at startup even with emacs -Q.  I don't know where this is coming from
> either, but it rings a dim bell---I'll try to investigate further.

The theme-face is coming from `font-setting-change-default-font' in
dynamic-settings.el:

    (let ((spec (list (list t (face-attr-construct 'default)))))
      (progn
        (put 'default 'customized-face spec)
        (custom-push-theme 'theme-face 'default 'user 'set spec)
        (put 'default 'face-modified nil))))))

As this function is written, it's not going to play nicely with the
Customize or Custom themes code.  It tries to apply the system font
settings by pretending that the user has customized the default face.
The problem is that user customizations override Custom themes.

bug#9982: Theme faces wrongly applied after background changes.

[Chong Yidong]

I've committed a patch to trunk that should fix the immediate problem.
The reason this bug triggered under XFCE is that XFCE sends Emacs a
`font-render' config event, and a font-setting-change-default-font bug
caused the default face to be modified even with font-use-system-font
nil.

This patch doesn't address the broader problem, noted in my previous
message: when font-use-system-font is non-nil, the way
font-setting-change-default-font uses custom-push-theme will likely
interefere with the user's own Custom settings and/or Custom themes.

I think that instead of using custom-push-theme,
font-setting-change-default-font should set a `font' frame parameter in
window-system-default-frame-alist.  Something like the following (needs
testing---I don't have Gconf libs installed at the moment).

Jan, WDYT?


=== modified file 'lisp/dynamic-setting.el'
*** lisp/dynamic-setting.el	2012-01-29 13:55:09 +0000
--- lisp/dynamic-setting.el	2012-01-29 14:09:40 +0000
***************
*** 75,86 ****
  
        ;; Set for future frames.
        (when set-font
! 	;; FIXME: this is not going to play well with Custom themes.
! 	(set-face-attribute 'default t :font new-font)
! 	(let ((spec (list (list t (face-attr-construct 'default)))))
! 	  (put 'default 'customized-face spec)
! 	  (custom-push-theme 'theme-face 'default 'user 'set spec)
! 	  (put 'default 'face-modified nil))))))
  
  (defun dynamic-setting-handle-config-changed-event (event)
    "Handle config-changed-event on the display in EVENT.
--- 75,88 ----
  
        ;; Set for future frames.
        (when set-font
! 	(let* ((ws (window-system))
! 	       (alist (assq ws window-system-default-frame-alist)))
! 	  (setq window-system-default-frame-alist
! 		(delq alist window-system-default-frame-alist))
! 	  (setq alist (cdr alist))
! 	  (setq alist (cons (cons 'font new-font)
! 			    (delq 'font alist)))
! 	  (push (cons ws alist) window-system-default-frame-alist))))))
  
  (defun dynamic-setting-handle-config-changed-event (event)
    "Handle config-changed-event on the display in EVENT.

bug#9982: Theme faces wrongly applied after background changes.

[Jan Djärv]

Hello.

29 jan 2012 kl. 15:14 skrev Chong Yidong:

> I've committed a patch to trunk that should fix the immediate problem.
> The reason this bug triggered under XFCE is that XFCE sends Emacs a
> `font-render' config event, and a font-setting-change-default-font bug
> caused the default face to be modified even with font-use-system-font
> nil.
> 
> This patch doesn't address the broader problem, noted in my previous
> message: when font-use-system-font is non-nil, the way
> font-setting-change-default-font uses custom-push-theme will likely
> interefere with the user's own Custom settings and/or Custom themes.
> 
> I think that instead of using custom-push-theme,
> font-setting-change-default-font should set a `font' frame parameter in
> window-system-default-frame-alist.  Something like the following (needs
> testing---I don't have Gconf libs installed at the moment).
> 
> Jan, WDYT?
> 

This does fix the bug.

	Jan D.

> 
> === modified file 'lisp/dynamic-setting.el'
> *** lisp/dynamic-setting.el	2012-01-29 13:55:09 +0000
> --- lisp/dynamic-setting.el	2012-01-29 14:09:40 +0000
> ***************
> *** 75,86 ****
> 
>        ;; Set for future frames.
>        (when set-font
> ! 	;; FIXME: this is not going to play well with Custom themes.
> ! 	(set-face-attribute 'default t :font new-font)
> ! 	(let ((spec (list (list t (face-attr-construct 'default)))))
> ! 	  (put 'default 'customized-face spec)
> ! 	  (custom-push-theme 'theme-face 'default 'user 'set spec)
> ! 	  (put 'default 'face-modified nil))))))
> 
>  (defun dynamic-setting-handle-config-changed-event (event)
>    "Handle config-changed-event on the display in EVENT.
> --- 75,88 ----
> 
>        ;; Set for future frames.
>        (when set-font
> ! 	(let* ((ws (window-system))
> ! 	       (alist (assq ws window-system-default-frame-alist)))
> ! 	  (setq window-system-default-frame-alist
> ! 		(delq alist window-system-default-frame-alist))
> ! 	  (setq alist (cdr alist))
> ! 	  (setq alist (cons (cons 'font new-font)
> ! 			    (delq 'font alist)))
> ! 	  (push (cons ws alist) window-system-default-frame-alist))))))
> 
>  (defun dynamic-setting-handle-config-changed-event (event)
>    "Handle config-changed-event on the display in EVENT.

bug#9982: Theme faces wrongly applied after background changes.

[Jan Djärv]

Hello.

29 jan 2012 kl. 14:28 skrev Chong Yidong:

> Chong Yidong <cyd@gnu.org> writes:
> 
>> I installed xfce4 and can now reproduce the bug.  The problem is the
>> existence of the `theme-face' property for `default', which is present
>> at startup even with emacs -Q.  I don't know where this is coming from
>> either, but it rings a dim bell---I'll try to investigate further.
> 
> The theme-face is coming from `font-setting-change-default-font' in
> dynamic-settings.el:
> 
>    (let ((spec (list (list t (face-attr-construct 'default)))))
>      (progn
>        (put 'default 'customized-face spec)
>        (custom-push-theme 'theme-face 'default 'user 'set spec)
>        (put 'default 'face-modified nil))))))
> 
> As this function is written, it's not going to play nicely with the
> Customize or Custom themes code.  It tries to apply the system font
> settings by pretending that the user has customized the default face.
> The problem is that user customizations override Custom themes.

Then does menu-set-font (the command for the menu choice "Set Default Font") have the same problem?  The code was taken from there.

	Jan D.

bug#9982: Theme faces wrongly applied after background changes.

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Then does menu-set-font (the command for the menu choice "Set Default
> Font") have the same problem?  The code was taken from there.

Yes, thanks for pointing this out.  I've committed a fix for this too.

bug#9982: M-x load-theme does not change background color

[Jan Djärv]

Hello.

I see this under XFCE and Arch Linux.  But not if I run Gnome on the same machine.
My guess is that some xfce-theme is buggy, much like the kde-gtk theme bridge is buggy.
XFCE seems to be quite buggy overall, it doesn't play sounds and can't get the keyboard layout right.

I'll see if we can work around this theme bug.  However, it is a pain to edit with the wrong keyboard layout :-).

	Jan D.


8 nov 2011 kl. 06:51 skrev Brendan Miller:

> I think I've narrowed down the bug somewhat. There is something wrong
> with the (set-background-color "color-here") function. This is a
> regression from emacs 23.3 where that function works fine on the same
> machine.
> 
> I tried (set-background-color "black") and this function seems very
> erratic. It will succeed part way (not for all lines on buffer), but
> then fail to set the color back to white on the next call. Assuming
> that load-theme uses this function, I think this is probably where the
> bug is.
> 
> I tried launching emacs with emacs --background-color=black, and that
> succeeds in making the background color black.
> 
> This is run under emacs -Q. I tried doing a git pull and recompiling
> everything just to be sure it's not already fixed.
> 
> I'm running under Arch Linux on XFCE. I followed the output of the
> ./configure script, and it seems I am building against GTK2 libraries.
> 
> I'll experiment a bit and see if I can narrow down the problem further.
> 
> I'm adding the diagnostic information from report-emacs-bug below. I
> was having trouble sending via report-emacs-bug method directly, as it
> didn't seem to like my smtp server.
> 
> In GNU Emacs 24.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.24.7)
> of 2011-11-07 on arch
> Windowing system distributor `The X.Org Foundation', version 11.0.11101902
> 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: en_US.UTF-8
>  value of $XMODIFIERS: nil
>  locale-coding-system: utf-8-unix
>  default enable-multibyte-characters: t
> 
> Major mode: Lisp Interaction
> 
> Minor modes in effect:
>  tooltip-mode: t
>  mouse-wheel-mode: t
>  tool-bar-mode: t
>  menu-bar-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
>  line-number-mode: t
>  transient-mark-mode: t
> 
> Recent input:
> M-x l o a d - t h e <tab> <return> m a n o <tab> <return>
> M-x r e p o r t - b u g <tab> <return>
> 
> Recent messages:
> For information about GNU Emacs and the GNU system, type C-h C-a.
> 
> Load-path shadows:
> None found.
> 
> Features:
> (shadow sort gnus-util mail-extr message format-spec rfc822 mml easymenu
> mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
> ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
> emacsbug manoj-dark-theme time-date tooltip ediff-hook vc-hooks
> lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe
> lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
> mouse jit-lock font-lock 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 indian
> cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
> minibuffer loaddefs button faces cus-face files text-properties overlay
> sha1 md5 base64 format env code-pages mule custom widget
> hashtable-print-readable backquote make-network-process dbusbind
> dynamic-setting system-font-setting font-render-setting move-toolbar gtk
> x-toolkit x multi-tty emacs)
> 
> 

Re: bug#9982: M-x load-theme does not change background color

[Daimrod]

Brendan Miller <catphive@catphive.net> writes:

> Another thought is that my XFCE environment has GTK3 libs installed,
> whereas the gnome environment has only GTK2 libs, so it might be
> related to that. Is there a way to check whether emacs is linking
> against GTK2 or GTK3?

C-h v system-configuration-options
Look at --with-x-toolkit=XXX