Re: Incorrect font weight selected

[Eli Zaretskii]

> From: Yuri D'Elia <wavexx@thregr.org>
> Cc: dgutov@yandex.ru, monnier@iro.umontreal.ca, larsi@gnus.org,
>  emacs-devel@gnu.org
> Date: Wed, 05 Jan 2022 17:19:35 +0100
> 
> After looking at this through a couple of times, I came up with the
> attached patch. When changing the default face, the resulting font
> name/pattern is stored as a string. Whenever a new frame is created, the
> string is used to re-open the face again. I guess this is done to
> support creating frames across different terminal types preserving the
> closest available font.
> 
> This is done by calling font_open_by_name, which builds up a font spec
> again from the stored string (which at this point _should_ be fully
> specified), then calls the font_open_by_spec. The problem seems that
> font_open_by_spec is _explicitly_ requesting a normal
> weight/slant/width. So if multiple candidates were available while
> enumerating fonts, the regular variant was always picked irregardless of
> our preference.
> 
> This used to work before since only a single variant was generally
> enumerated. In the patch, instead of just resetting/overriding the spec,
> we just preset a normal variant if the spec is incomplete. I included
> also the family/foundry in the spec, which can be used during selection
> instead of blindly ignoring it.
> 
> This seems to work correctly for me now, however I'm only testing on
> x11. font_open_by_name is not used in many places aside frame creation.
> This change seems coherent to me looking at the other calls.

Thanks, but this is a scary change.  I have no idea what unintended
consequences it could cause.

Can we back up a bit, and understand how the change in 1b2511f
triggered the problems you see?  If you already understand that, can
you describe it?  Maybe we could then come up with a safer, better
understood change.  If nothing better comes to mind, I'd prefer to
revert 1b2511f than doing something like what you propose.