bug#59347: 29.0.50; `:family` face setting ignored

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  59347@debbugs.gnu.org
> Date: Wed, 07 Dec 2022 19:27:28 -0500
> 
> >> My question was not about this basic relative importance, it was about
> >> something else: when none of the fonts of the given FAMILY fits the font
> >> spec, why do you consider keeping the family to be more important than
> >> keeping the weight?
> > I don't understand your question.  If we agree that there is an order of
> > importance in the attributes of a font spec,
> 
> Why should we agree on that?
> 
> When I specify the `:family` property on the `variable-pitch` face,
> I definitely want it to take precedence over the `:weight` of the
> default face, yes.
> 
> But when I specify the `weight` property of the `bold` face, it's not
> clear at all that the `:family` of the default face should take precedence
> over the `:weight` of the `bold` face.

If we want to distinguish between explicitly requested attributes and
inherited attributes, we need to store this information inside the
font spec.  (We have the :user-spec attribute, but it is used for
slightly different purposes.)

Please also note that explicit requests for attributes can come from a
Lisp program, not from the user.

> FWIW, I've been running with your patch and I like the result.

Which patch is that?  The one proposed in the message to which you are
responding, or one of the earlier ones?

> Maybe the ordering should depend on the "stacking order" of the faces
> and their properties.  I.e. instead of merging `bold+variable-pitch+default` 
> to get
> a set of properties on which we apply a globally-imposed ordering, we
> could keep track of the relative ordering of the properties: `bold` was
> on top, so the `:weight` property comes first, then came
> `variable-pitch` so its `:family` property comes second and the second
> comes afterwards.
> 
> So `bold+variable-pitch+default` could result in a different font than
> `variable-pitch+bold+default` even if the combined properties (i.e. the
> merged face) are identical.

How would you determine the order in the stack?  IOW, which attributes
will be "the first"?