bug#19117: 25.0.50; emacs on x11 chooses different fonts for the same face sometimes

[Eli Zaretskii <eliz@gnu.org>]

> From: Dima Kogan <dima@secretsauce.net>
> Date: Sat, 06 Dec 2014 23:28:34 -0800
> 
> > Put a breakpoint where Emacs loads new fonts, and see who calls that
> > code.
> 
> I'm digging through the code. It's slow going so far, but I'm getting
> more familiar with it. In my init.el I have in my default-frame-alist
> 
>  (font . "-adobe-courier-medium-r-*-*-*-80-*-*-m-*-iso8859-1")
> 
> I'm looking at realize_x_face() in xfaces.c. When I create a new frame
> by pressing C-x 5 2, all the faces get re-realized, and I can see which
> fonts are chosen. That function takes in a list of face attributes, and
> associates a font with each face. I'm looking at attrs[LFACE_FONT_INDEX]
> on input and face->font on output. For most faces, these two values are
> 
>  #<font-object "-adobe-courier-medium-r-normal--11-80-100-100-m-60-iso8859-1">
>  "-adobe-courier-medium-r-normal--11-80-100-100-m-60-iso8859-1"
> 
> which is correct: we're asking for a particular font and we're getting
> it.

the above is a font object.

> For many faces, however these values are
> 
>  #<font-spec nil adobe courier ## iso8859-1 medium nil normal 11 100 100 60 ((user-spec . "-adobe-courier-medium-r-*-*-*-80-*-*-m-*-iso8859-1"))>
>  "-urw-nimbus mono l-regular-o-normal--11-79-100-100-p-70-iso8859-1"
> 
> or
> 
>  #<font-spec nil adobe courier ## iso8859-1 medium nil normal 11 100 100 60 ((user-spec . "-adobe-courier-medium-r-*-*-*-80-*-*-m-*-iso8859-1"))>
>  "-adobe-courier-medium-o-normal--11-80-100-100-m-60-iso8859-1"

These two aren't font objects, they are font specs, a different
object.  See font.h for their respective descriptions (unless you
already read that).

> Here we're requesting a slanted version of the default font. Sometimes
> emacs picks the right one (-adobe-courier-medium-o-...), but at other
> times it picks the wrong one (-urw-....). The exact set of faces that
> get the wrong font varies with each invocation of realize_x_face(), but
> there's always at least one wrong one.

Does the backtrace tell something about the reason(s) for the
differences?