bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Yuan Fu
Subject: bug#59347: 29.0.50; `:family` face setting ignored
Date: Wed, 7 Dec 2022 21:32:48 -0800


> On Dec 7, 2022, at 4:27 PM, Stefan Monnier via Bug reports for GNU Emacs, the 
> Swiss army knife of text editors <bug-gnu-emacs@gnu.org> wrote:
> 
>>> 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.
> 
> FWIW, I've been running with your patch and I like the result.  I think
> it's better overall, but I suspect that we still have a fundamental
> problem with this notion of precedence/ordering.
> 
> 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.

IIUC currently all faces are realized into a “realized face”, where each 
attribute is filled in with parent faces’ attributes. So there is no difference 
between an explicitly assigned attribute and an inherited attribute at the time 
when Emacs selects fonts. But if I assign only :family attribute to a face, and 
that face inherits a :weight attribute, naturally the :family face should take 
precedence when selecting fonts. OTOH if I explicitly assign a :weight 
attribute, and the :family attribute is inherited, then :weight should probably 
take precedence.

IIUC you are just describing a generalized version of this strategy, right? I 
think it’s a good idea. Even if we don’t generalize it into a “stacking order”, 
but only record what’s inherited and what’s assigned explicitly, and prioritize 
the explicitly assigned attributes, it would produce more intuitive results, I 
think.

Yuan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]