[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#59347: 29.0.50; `:family` face setting ignored
From: |
Gregory Heytings |
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.
- bug#59347: 29.0.50; `:family` face setting ignored, (continued)
- bug#59347: 29.0.50; `:family` face setting ignored, Po Lu, 2022/12/12
- bug#59347: 29.0.50; `:family` face setting ignored, Gregory Heytings, 2022/12/12
- bug#59347: 29.0.50; `:family` face setting ignored, Po Lu, 2022/12/12
- bug#59347: 29.0.50; `:family` face setting ignored, Gregory Heytings, 2022/12/12
- bug#59347: 29.0.50; `:family` face setting ignored, Po Lu, 2022/12/12
- bug#59347: 29.0.50; `:family` face setting ignored, Stefan Monnier, 2022/12/12
- bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/12/12
- bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/12/12
- bug#59347: 29.0.50; `:family` face setting ignored, Gregory Heytings, 2022/12/12
- bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/12/12
- bug#59347: 29.0.50; `:family` face setting ignored,
Gregory Heytings <=
- bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/12/13
- bug#59347: 29.0.50; `:family` face setting ignored, Po Lu, 2022/12/12
- bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/12/13
bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/12/04