bug#16440: 24.3.50; Some colors of the theme aren't respected in latest Emacs

bug#16440: 24.3.50; Some colors of the theme aren't respected in latest Emacs

[Sebastien Vauban]

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

Re: bug#16440: 24.3.50; Some colors of the theme aren't respected in latest Emacs

[Sebastien Vauban]

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

bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Sebastien Vauban]

Please note that the crash occurred with Emacs 24.3.50 (r114715) from
2013-10-19.

I reported it with another Emacs version, because I suddenly found that
Emacs I'm normally using was quite unstable.

bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Eli Zaretskii]

> From: "Sebastien Vauban" <sva-news@mygooglest.com>
> Date: Mon, 17 Feb 2014 16:57:10 +0100
> 
> Please note that the crash occurred with Emacs 24.3.50 (r114715) from
> 2013-10-19.

That's a very old version.

bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Sebastien Vauban]

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.

Best regards,
  Seb

-- 
Sebastien Vauban

bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Eli Zaretskii]

> From: "Sebastien Vauban" <sva-news@mygooglest.com>
> Cc: 16780@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.

bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Sebastien Vauban]

Eli Zaretskii wrote:
>> From: "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
>> Cc: 16780-ubl+/3LiMTaZdePnXv/OxA@public.gmane.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.

Best regards,
  Seb

-- 
Sebastien Vauban

bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Eli Zaretskii]

> From: "Sebastien Vauban" <sva-news@mygooglest.com>
> Cc: 16780@debbugs.gnu.org
> Date: Mon, 17 Feb 2014 22:23:03 +0100
> 
> Eli Zaretskii wrote:
> >> From: "Sebastien Vauban" <sva-news@mygooglest.com>
> >> Cc: 16780@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.

bug#16440: bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Sebastien Vauban]

"Sebastien Vauban" wrote:
> Eli Zaretskii wrote:
>>> From: "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
>>> Cc: 16780-ubl+/3LiMTaZdePnXv/OxA@public.gmane.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

bug#16440: bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Sebastien Vauban]

Eli Zaretskii wrote:
>> From: "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
>> Cc: 16780-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org
>> Date: Mon, 17 Feb 2014 22:23:03 +0100
>> 
>> Eli Zaretskii wrote:
>> >> From: "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
>> >> Cc: 16780-ubl+/3LiMTaZdePnXv/OxA@public.gmane.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

bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Eli Zaretskii]

> From: "Sebastien Vauban" <sva-news@mygooglest.com>
> Cc: 16780@debbugs.gnu.org, 16440@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?

bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Glenn Morris]

Eli Zaretskii wrote:

>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16440
[...]
> ??? That one was solved ages ago, AFAIK.

I don't think so. I think 16434, 16440, 16443, 16694 are all related.
See http://debbugs.gnu.org/16694#8

bug#16440: bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Sebastien Vauban]

Eli Zaretskii wrote:
>> From: "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
>> Cc: 16780-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org, 16440-ubl+/3LiMTaZdePnXv/OxA@public.gmane.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

bug#16440: bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Eli Zaretskii]

> From: "Sebastien Vauban" <sva-news@mygooglest.com>
> Cc: 16440@debbugs.gnu.org, rgm@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.

bug#16440: bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Sebastien Vauban]

Eli Zaretskii wrote:
>> From: "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
>> Cc: 16440-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org, rgm-mXXj517/zsQ@public.gmane.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

bug#16440: bug#16780: 24.2.91; Emacs crash when C-c C-c on captured item

[Eli Zaretskii]

> From: "Sebastien Vauban" <sva-news@mygooglest.com>
> Cc: 16440@debbugs.gnu.org,  rgm@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.)