GNU bug report logs - #16440
24.3.50; Some colors of the theme aren't respected in latest Emacs

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 16440 in the body.
You can then email your comments to 16440 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: "Sebastien Vauban" <sva-news <at> mygooglest.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Some colors of the theme aren't respected in latest Emacs
Date: Tue, 14 Jan 2014 13:32:42 +0100

Hello,

Because of the performance problem (with some Unicode chars), I'm still
using GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-10-19 on LEG570 for
a while.

Now, I tried to move to one of the latest versions made available by
Dani. The performance problem has disappeared, but there are some
problems with the color theme (Leuven [1], in my case).

See http://screencast.com/t/kvuLrvtVZ2l6 for a comparison of how the
faces were displayed in older Emacs and in the current one.

What's weird is that there are differences in the face specifications
which are seen by both Emacs: see http://screencast.com/t/gsyeXp40TAa.
Though, both Emacs are run in the exact same way, with the exact same
versions of the color theme, and with the exact same version of Org.

Best regards,
  Seb

[1] Which is present in the current trunk.

-- 
Sebastien Vauban

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

From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
To: 16440 <at> debbugs.gnu.org
Cc: emacs-orgmode <at> gnu.org
Subject: Re: bug#16440: 24.3.50;
 Some colors of the theme aren't respected in latest Emacs
Date: Wed, 22 Jan 2014 10:39:31 +0100

Hello,

> See http://screencast.com/t/kvuLrvtVZ2l6 for a comparison of how the
> faces were displayed in older Emacs and in the current one.

Giving more "data points" on this with a MINIMAL Emacs configuration
(proving, if needs be, that it isn't due to something misconfigured in
my long configuration file):

  $ /cygdrive/c/Program\ Files\ \(x86\)/emacs-r114715-20131019-w32/bin/emacs -q -l ~/.emacs-minimal.el &

vs.

  $ /cygdrive/c/Program\ Files\ \(x86\)/emacs-trunk/bin/emacs -q -l ~/.emacs-minimal.el &

(where trunk version is r116068 from 2014-01-19).

- At startup already, the logo is black and white in the newest Emacs.
  See http://screencast.com/t/ZU2oEOrVqm.

- When opening an Org file with code blocks, the "code delimiters"
  aren't correctly rendered.
  See http://screencast.com/t/gLcMVvvgd9Ac.

Minimal Emacs configuration file:

--8<---------------cut here---------------start------------->8---
(message "Loading Minimal Emacs...")

(setq frame-title-format
      (format "Minimal Emacs %s rev:%s of %s    PID:%d"
              ;; (capitalize (symbol-name system-type))
              emacs-version
              (ignore-errors
                (replace-regexp-in-string " .*" "" emacs-bzr-version))
              (format-time-string "%Y-%m-%d" emacs-build-time)
              (emacs-pid)))

(add-to-list 'load-path "~/git/org-mode/lisp")

(load-theme 'leuven t)
--8<---------------cut here---------------end--------------->8---

Best regards,
  Seb

-- 
Sebastien Vauban

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

From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
To: Eli Zaretskii <eliz <at> gnu.org>,  16780 <at> debbugs.gnu.org
Cc: 16440 <at> debbugs.gnu.org
Subject: Re: bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item
Date: Mon, 17 Feb 2014 22:33:11 +0100

"Sebastien Vauban" wrote:
> Eli Zaretskii wrote:
>>> From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
>>> Cc: 16780 <at> debbugs.gnu.org
>>> Date: Mon, 17 Feb 2014 22:10:23 +0100
>>> 
>>> Eli Zaretskii wrote:
>>> >> Please note that the crash occurred with Emacs 24.3.50 (r114715) from
>>> >> 2013-10-19.
>>> >
>>> > That's a very old version.
>>> 
>>> Yes, I'm not really fond of using a more recent version because of the
>>> following bug:
>>> 
>>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16440
>>> 
>>> which affects parts of my display.
>>
>> ??? That one was solved ages ago, AFAIK.
>
> I'm not sure by what you mean by "ages ago".
>
> I just see it's still open (there has even been 0 comments on it), and
> I do have it in GNU Emacs 24.3.50.1 (r116256) of 2014-02-03.

I just see that Dani uploaded a new version of Emacs:

   GNU Emacs 24.3.50.1 (116464) of 2014-02-17.

I tested the bug #16440 against it, and I still have it.

Best regards,
  Seb

-- 
Sebastien Vauban

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

From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16440 <at> debbugs.gnu.org, 16780 <at> debbugs.gnu.org
Subject: Re: bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item
Date: Mon, 17 Feb 2014 22:39:33 +0100

Eli Zaretskii wrote:
>> From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
>> Cc: 16780 <at> debbugs.gnu.org
>> Date: Mon, 17 Feb 2014 22:23:03 +0100
>> 
>> Eli Zaretskii wrote:
>> >> From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
>> >> Cc: 16780 <at> debbugs.gnu.org
>> >> Date: Mon, 17 Feb 2014 22:10:23 +0100
>> >> 
>> >> Eli Zaretskii wrote:
>> >> >> Please note that the crash occurred with Emacs 24.3.50 (r114715) from
>> >> >> 2013-10-19.
>> >> >
>> >> > That's a very old version.
>> >> 
>> >> Yes, I'm not really fond of using a more recent version because of the
>> >> following bug:
>> >> 
>> >> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16440
>> >> 
>> >> which affects parts of my display.
>> >
>> > ??? That one was solved ages ago, AFAIK.
>> 
>> I'm not sure by what you mean by "ages ago".
>> 
>> I just see it's still open (there has even been 0 comments on it), and
>> I do have it in GNU Emacs 24.3.50.1 (r116256) of 2014-02-03.
>
> With just this line in my .emacs:
>
>   (load-theme 'leuven t)
>
> I cannot reproduce the picture you show in the report.  I see a color
> Gnu head.
>
> What image types do you have available in the problematic binary?
> This could be some incompatibility between the image libraries against
> which Dani built his binary and the DLLs you have installed on your
> system.  See README.W32 and/or nt/INSTALL for the details.

This is mainly on specific faces (not all, just a minority) not being
applied...

See http://screencast.com/t/m2urFNhsSrN for a comparison, with all
parameters identical (same config file, same theme file), but the
version of the Emacs binary...

Best regards,
  Seb

-- 
Sebastien Vauban

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sebastien Vauban <sva-news <at> mygooglest.com>
Cc: 16440 <at> debbugs.gnu.org, 16780 <at> debbugs.gnu.org
Subject: Re: bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item
Date: Mon, 17 Feb 2014 23:47:15 +0200

> From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
> Cc: 16780 <at> debbugs.gnu.org, 16440 <at> debbugs.gnu.org
> Date: Mon, 17 Feb 2014 22:39:33 +0100
> 
> > With just this line in my .emacs:
> >
> >   (load-theme 'leuven t)
> >
> > I cannot reproduce the picture you show in the report.  I see a color
> > Gnu head.
> >
> > What image types do you have available in the problematic binary?
> > This could be some incompatibility between the image libraries against
> > which Dani built his binary and the DLLs you have installed on your
> > system.  See README.W32 and/or nt/INSTALL for the details.
> 
> This is mainly on specific faces (not all, just a minority) not being
> applied...

Your screencast shows a black-and-white Gnu head.  Is that still a
problem?  Then please tell what does evaluating the following produce
in "emacs -Q":

  (mapcar (lambda (elt)
	    (list (car elt) (image-type-available-p (car elt))))
	  dynamic-library-alist)

> See http://screencast.com/t/m2urFNhsSrN for a comparison, with all
> parameters identical (same config file, same theme file), but the
> version of the Emacs binary...

What faces?  Can you provide a simple, small, self-contained test
case?

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

From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16440 <at> debbugs.gnu.org, rgm <at> gnu.org
Subject: Re: bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item
Date: Tue, 18 Feb 2014 09:37:45 +0100

Eli Zaretskii wrote:
>> From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
>> Cc: 16780 <at> debbugs.gnu.org, 16440 <at> debbugs.gnu.org
>> Date: Mon, 17 Feb 2014 22:39:33 +0100
>> 
>> > With just this line in my .emacs:
>> >
>> >   (load-theme 'leuven t)
>> >
>> > I cannot reproduce the picture you show in the report.  I see a color
>> > Gnu head.
>> >
>> > What image types do you have available in the problematic binary?
>> > This could be some incompatibility between the image libraries against
>> > which Dani built his binary and the DLLs you have installed on your
>> > system.  See README.W32 and/or nt/INSTALL for the details.
>> 
>> This is mainly on specific faces (not all, just a minority) not being
>> applied...
>
> Your screencast shows a black-and-white Gnu head.  Is that still a
> problem?

The Gnu head is with an orange background (#FF8C00). See
http://screencast.com/t/s6sWP3Nsc.

That seems to be the invert of what it should (as specified in the
Leuven theme):

--8<---------------cut here---------------start------------->8---
   `(gnus-splash ((,class (:foreground "#FF8C00"))))
--8<---------------cut here---------------end--------------->8---

> Then please tell what does evaluating the following produce
> in "emacs -Q":
>
>   (mapcar (lambda (elt)
> 	    (list (car elt) (image-type-available-p (car elt))))
> 	  dynamic-library-alist)

See http://screencast.com/t/SmhmZ629B:

  ╭────
  │ ((xpm nil) (png nil) (tiff nil) (jpeg nil) (gif nil) (svg nil)
  │ (gdk-pixbuf nil) (glib nil) (gobject nil) (gnutls nil) (libxml2 nil)
  │ (zlib nil))
  ╰────

>> See http://screencast.com/t/m2urFNhsSrN for a comparison, with all
>> parameters identical (same config file, same theme file), but the
>> version of the Emacs binary...
>
> What faces?  Can you provide a simple, small, self-contained test
> case?

New screenshot: http://screencast.com/t/LDKtOSOB.

Test file:

--8<---------------cut here---------------start------------->8---
* Code block

#+begin_src emacs-lisp
;; the above line must be displayed as `org-block-begin-line'
(message "echo")                        ; a line of code, such as this one, is
                                        ; displayed as `org-block-background'
;; the line below this one must be displayed as `org-block-end-line'
#+end_src

* Mail contents

#+begin_verse
The "borders" of this block must be displayed as `org-block-begin/end-line'.

The "inside" must be displayed as `org-verse'...

Foo
Bar
Baz
#+end_verse
--8<---------------cut here---------------end--------------->8---

Best regards,
  Seb

-- 
Sebastien Vauban

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sebastien Vauban <sva-news <at> mygooglest.com>
Cc: 16440 <at> debbugs.gnu.org, rgm <at> gnu.org
Subject: Re: bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item
Date: Tue, 18 Feb 2014 20:04:47 +0200

> From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
> Cc: 16440 <at> debbugs.gnu.org, rgm <at> gnu.org
> Date: Tue, 18 Feb 2014 09:37:45 +0100
> 
> >> > What image types do you have available in the problematic binary?
> >> > This could be some incompatibility between the image libraries against
> >> > which Dani built his binary and the DLLs you have installed on your
> >> > system.  See README.W32 and/or nt/INSTALL for the details.
> >> 
> >> This is mainly on specific faces (not all, just a minority) not being
> >> applied...
> >
> > Your screencast shows a black-and-white Gnu head.  Is that still a
> > problem?
> 
> The Gnu head is with an orange background (#FF8C00). See
> http://screencast.com/t/s6sWP3Nsc.

It is still mono-color, which isn't right.

> That seems to be the invert of what it should (as specified in the
> Leuven theme):
> 
> --8<---------------cut here---------------start------------->8---
>    `(gnus-splash ((,class (:foreground "#FF8C00"))))
> --8<---------------cut here---------------end--------------->8---

That's gnus-splash, not Emacs splash, right?  Or am I missing
something?

> > Then please tell what does evaluating the following produce
> > in "emacs -Q":
> >
> >   (mapcar (lambda (elt)
> > 	    (list (car elt) (image-type-available-p (car elt))))
> > 	  dynamic-library-alist)
> 
> See http://screencast.com/t/SmhmZ629B:
> 
>   ╭────
>   │ ((xpm nil) (png nil) (tiff nil) (jpeg nil) (gif nil) (svg nil)
>   │ (gdk-pixbuf nil) (glib nil) (gobject nil) (gnutls nil) (libxml2 nil)
>   │ (zlib nil))
>   ╰────

You don't have any image libraries available.  If that bothers you,
read README.W32 or nt/INSTALL.

> >> See http://screencast.com/t/m2urFNhsSrN for a comparison, with all
> >> parameters identical (same config file, same theme file), but the
> >> version of the Emacs binary...
> >
> > What faces?  Can you provide a simple, small, self-contained test
> > case?
> 
> New screenshot: http://screencast.com/t/LDKtOSOB.
> 
> Test file:
> 
> --8<---------------cut here---------------start------------->8---
> * Code block
> 
> #+begin_src emacs-lisp
> ;; the above line must be displayed as `org-block-begin-line'
> (message "echo")                        ; a line of code, such as this one, is
>                                         ; displayed as `org-block-background'
> ;; the line below this one must be displayed as `org-block-end-line'
> #+end_src
> 
> * Mail contents
> 
> #+begin_verse
> The "borders" of this block must be displayed as `org-block-begin/end-line'.
> 
> The "inside" must be displayed as `org-verse'...
> 
> Foo
> Bar
> Baz
> #+end_verse
> --8<---------------cut here---------------end--------------->8---

OK, but what should one do with this file, starting with "emacs -Q",
to reproduce the problem?  The screenshot only shows the results, not
what you did to achieve them.

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

From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16440 <at> debbugs.gnu.org, rgm <at> gnu.org
Subject: Re: bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item
Date: Tue, 18 Feb 2014 19:51:48 +0100

Eli Zaretskii wrote:
>> From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
>> Cc: 16440 <at> debbugs.gnu.org, rgm <at> gnu.org
>> Date: Tue, 18 Feb 2014 09:37:45 +0100
>> 
>> >> > What image types do you have available in the problematic binary?
>> >> > This could be some incompatibility between the image libraries against
>> >> > which Dani built his binary and the DLLs you have installed on your
>> >> > system.  See README.W32 and/or nt/INSTALL for the details.
>> >> 
>> >> This is mainly on specific faces (not all, just a minority) not being
>> >> applied...
>> >
>> > Your screencast shows a black-and-white Gnu head.  Is that still a
>> > problem?
>> 
>> The Gnu head is with an orange background (#FF8C00). See
>> http://screencast.com/t/s6sWP3Nsc.
>
> It is still mono-color, which isn't right.
>
>> That seems to be the invert of what it should (as specified in the
>> Leuven theme):
>> 
>> --8<---------------cut here---------------start------------->8---
>>    `(gnus-splash ((,class (:foreground "#FF8C00"))))
>> --8<---------------cut here---------------end--------------->8---
>
> That's gnus-splash, not Emacs splash, right?  Or am I missing
> something?

OK, right, I've confonded both. Because Gnus splash doesn't look right
either.

Regarding the Emacs splash, yes, I still have it in black-and-white.

>> > Then please tell what does evaluating the following produce
>> > in "emacs -Q":
>> >
>> >   (mapcar (lambda (elt)
>> > 	    (list (car elt) (image-type-available-p (car elt))))
>> > 	  dynamic-library-alist)
>> 
>> See http://screencast.com/t/SmhmZ629B:
>> 
>>   ╭────
>>   │ ((xpm nil) (png nil) (tiff nil) (jpeg nil) (gif nil) (svg nil)
>>   │ (gdk-pixbuf nil) (glib nil) (gobject nil) (gnutls nil) (libxml2 nil)
>>   │ (zlib nil))
>>   ╰────
>
> You don't have any image libraries available.  If that bothers you,
> read README.W32 or nt/INSTALL.

I'll do.

>> >> See http://screencast.com/t/m2urFNhsSrN for a comparison, with all
>> >> parameters identical (same config file, same theme file), but the
>> >> version of the Emacs binary...
>> >
>> > What faces?  Can you provide a simple, small, self-contained test
>> > case?
>> 
>> New screenshot: http://screencast.com/t/LDKtOSOB.
>> 
>> Test file:
>> 
>> --8<---------------cut here---------------start------------->8---
>> * Code block
>> 
>> #+begin_src emacs-lisp
>> ;; the above line must be displayed as `org-block-begin-line'
>> (message "echo")                        ; a line of code, such as this one, is
>>                                         ; displayed as `org-block-background'
>> ;; the line below this one must be displayed as `org-block-end-line'
>> #+end_src
>> 
>> * Mail contents
>> 
>> #+begin_verse
>> The "borders" of this block must be displayed as `org-block-begin/end-line'.
>> 
>> The "inside" must be displayed as `org-verse'...
>> 
>> Foo
>> Bar
>> Baz
>> #+end_verse
>> --8<---------------cut here---------------end--------------->8---
>
> OK, but what should one do with this file, starting with "emacs -Q",
> to reproduce the problem?  The screenshot only shows the results, not
> what you did to achieve them.

As stated in the beginning of the thread, simply launch a minimal Emacs
file (see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16440#10), and
open the above test file, for you to reproduce the problem.

Best regards,
  Seb

-- 
Sebastien Vauban

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sebastien Vauban <sva-news <at> mygooglest.com>, Bastien <bzg <at> altern.org>
Cc: 16440 <at> debbugs.gnu.org, rgm <at> gnu.org
Subject: Re: bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item
Date: Thu, 20 Feb 2014 18:35:15 +0200

> From: "Sebastien Vauban" <sva-news <at> mygooglest.com>
> Cc: 16440 <at> debbugs.gnu.org,  rgm <at> gnu.org
> Date: Tue, 18 Feb 2014 19:51:48 +0100
> 
> >> >> See http://screencast.com/t/m2urFNhsSrN for a comparison, with all
> >> >> parameters identical (same config file, same theme file), but the
> >> >> version of the Emacs binary...
> >> >
> >> > What faces?  Can you provide a simple, small, self-contained test
> >> > case?
> >> 
> >> New screenshot: http://screencast.com/t/LDKtOSOB.
> >> 
> >> Test file:
> >> 
> >> --8<---------------cut here---------------start------------->8---
> >> * Code block
> >> 
> >> #+begin_src emacs-lisp
> >> ;; the above line must be displayed as `org-block-begin-line'
> >> (message "echo")                        ; a line of code, such as this one, is
> >>                                         ; displayed as `org-block-background'
> >> ;; the line below this one must be displayed as `org-block-end-line'
> >> #+end_src
> >> 
> >> * Mail contents
> >> 
> >> #+begin_verse
> >> The "borders" of this block must be displayed as `org-block-begin/end-line'.
> >> 
> >> The "inside" must be displayed as `org-verse'...
> >> 
> >> Foo
> >> Bar
> >> Baz
> >> #+end_verse
> >> --8<---------------cut here---------------end--------------->8---
> >
> > OK, but what should one do with this file, starting with "emacs -Q",
> > to reproduce the problem?  The screenshot only shows the results, not
> > what you did to achieve them.
> 
> As stated in the beginning of the thread, simply launch a minimal Emacs
> file (see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16440#10), and
> open the above test file, for you to reproduce the problem.

If you reload the theme after visiting the Org file, those faces
change their looks to what you expect.

This seems to be the consequence of the change described in NEWS like
this:

  *** Face specs set via Custom themes now replace the `defface' spec
  rather than inheriting from it (as do face specs set via Customize).

Org uses org-copy-face to define the faces that you show in your
screencast, and org-copy-face assumes the face it inherits from
already exists.  But loading a theme now doesn't create the faces, it
only prepares the data for when the face will be created.  So :inherit
in org-copy-face doesn't do what you expect.

I guess either some change is needed in how themes are handled, or
org-copy-face needs to change to follow suit.  (CC to Bastien for
that.)

Previous Next

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