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 16:12:22 +0000

>
> your reaction, in particular the revert, is also overreaction.
>

Okay.  But note that it wasn't a blunt revert, it was accompanied with a 
long, precise, detailed rationale.  Unlike the commit it reverted, and the 
revert revert.

>> The fundamental problem I have with the doc string is that it did not 
>> say what it does, or what it is supposed to debug, in a manner users 
>> can understand.
>
> Does the current doc string have any such problems you can spot?
>

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."

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 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_.

This was also important:

"There is no reason to change that value except for debugging purposes."

Of course users are free to ignore that warning, but at least they have 
been warned.

>
> Anyway, here's my proposal:
>
> . we change the default value of the variable to be t, and document that 
> this stands for (:weight :width :slant)
>
> . we change the code to reset only those 3 attributes when the value is 
> t, and to reset nothing when the value is nil
>
> . the (slower) code which loops over the list will only run if the value 
> of the variable is neither nil nor t
>
> . we avoid resetting the :extra attribute on Haiku
>

As long as we don't traverse a Lisp list each time a face is realized in 
the default case, I'm fine with this.  I think Stefan's proposal (write an 
Elisp-level interface) is slightly better, though, because if we find out 
in Emacs 30 or 31 that some other attribute must also be unset, the 
meaning of 't' would have to change.

Previous Next

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