GNU bug report logs - #59347
29.0.50; `:family` face setting ignored

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, monnier <at> iro.umontreal.ca, 59347 <at> debbugs.gnu.org
Subject: bug#59347: 29.0.50; `:family` face setting ignored
Date: Mon, 12 Dec 2022 21:28:58 +0000

>> Yes.  The gist of the original docstring, which was correct (and I 
>> think understandable even by non-experts), is this:
>>
>> "When the font chosen for the default face has a weight, slant or width 
>> that is not supported by other available fonts on the system, such as 
>> 'medium', Emacs may select suboptimal fonts for other faces."
>
> This was important when the default value was hard to understand.  It is 
> less important when the default value is easily understood and 
> interpreted.  I will add something along these lines when I will change 
> the default to t, because then the effect will again be less clear.
>

Indeed, but what I meant is that the conditions in which that variable is 
useful / has an effect, and the intended effect, were indicated in the 
original docstring:

If the font chosen for the _default_ face has an attribute value that is 
not supported by other available fonts on the system,

then the font chosen for _other_ faces [in which that attribute is 
unspecified] may be suboptimal.

The part between brackets was missing from the original docstring.

>> As I explained, the root of this bug is an undesirable interaction with 
>> the weight/slant/widht (and possibly other attributes, time will tell 
>> us) of the _default_ face, when they are set to unusual/less common 
>> values, with the fonts that are selected for _other faces_ in which 
>> these attributes are _unspecified_.
>
> That is the case that was in your mind, but that is not the only case 
> where realize_gui_face is called.  It is also called when faces are 
> merged (which happens a lot in Emacs), and in a few other cases.  In 
> those cases I think the situation is less black-and-white, since each 
> attribute can come from a different face, or be inherited.
>

Would you mind giving a few more details?  I don't really understand what 
you mean here.

>> That is a very specific corner case, and the current variable name and 
>> docstring does not reflect this (namely, that it's a very specific 
>> corner case, in a very specific area of code).  The current docstring 
>> means something completely different.  Saying for example that "face 
>> attributes will be treated as "soft" constraints when looking for 
>> suitable fonts: if an exact match is not possible, a font can be 
>> selected that is a close, but not an exact, match" means that when an 
>> attribute is _specified_ Emacs will treat that attribute value in a lax 
>> manner, which is already (and has always been) the case, and when the 
>> purpose of that variable is to affect font selection for faces whose 
>> attributes are _unspecified_.
>
> When you say that it "is already (and has always been) the case", AFAIU 
> you are talking about the lower-level code, not about the level on which 
> this new variable makes a difference.  On this level, the match is 
> required to be exact, and clearing some attributes allows it to be 
> "lax".  Otherwise, why did we make this change, if the constraints were 
> already not "hard"?
>

Again I'm not sure I understand what you mean.  What I meant is that Emacs 
treats the attribute values of faces in a lax way, and always did.  After

(set-face-attribute 'variable-pitch nil :weight 'medium)

there is no guarantee that the font used for the variable-pitch face has a 
medium weight, IOW, that weight is not a hard constraint.  The only 
guarantee is that, after this call, Emacs will prefer, for that face, a 
regular font to a light one, or a semi-bold font to a bold one.

The fact that, after 6b1ed2f2c9, the attribute values of the default face 
became hard constraints for other faces in which these attributes are 
unspecified is a bug, that this change fixes.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.