From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#59347: 29.0.50; `:family` face setting ignored Date: Tue, 13 Dec 2022 13:58:32 +0200 Message-ID: <831qp3qzvb.fsf@gnu.org> References: <83bkp04gjl.fsf@gnu.org> <83leo42vm9.fsf@gnu.org> <0d1ea3007fd94b7ae0b1@heytings.org> <83r0xv1649.fsf@gnu.org> <0d1ea3007f532a493429@heytings.org> <83cz9f12bh.fsf@gnu.org> <835yewleyn.fsf@gnu.org> <83tu2b9rlx.fsf@gnu.org> <83k0347gtu.fsf@gnu.org> <83v8mm2ug7.fsf@gnu.org> <83cz8u2d6u.fsf@gnu.org> <831qp93nsc.fsf@gnu.org> <1a7e3acf3578520feda7@heytings.org> <831qp4slt0.fsf@gnu.org> <83o7s8r1i7.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19240"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, 59347@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 13 12:59:36 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p53wd-0004pw-GF for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Dec 2022 12:59:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p53wU-0002If-3v; Tue, 13 Dec 2022 06:59:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p53w8-0002I3-AC for bug-gnu-emacs@gnu.org; Tue, 13 Dec 2022 06:59:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p53w6-0008CX-Of for bug-gnu-emacs@gnu.org; Tue, 13 Dec 2022 06:59:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p53w6-000436-06 for bug-gnu-emacs@gnu.org; Tue, 13 Dec 2022 06:59:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Dec 2022 11:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59347 X-GNU-PR-Package: emacs Original-Received: via spool by 59347-submit@debbugs.gnu.org id=B59347.167093271715554 (code B ref 59347); Tue, 13 Dec 2022 11:59:01 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 13 Dec 2022 11:58:37 +0000 Original-Received: from localhost ([127.0.0.1]:59879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p53vg-00042o-KD for submit@debbugs.gnu.org; Tue, 13 Dec 2022 06:58:37 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p53vf-00042h-5s for 59347@debbugs.gnu.org; Tue, 13 Dec 2022 06:58:35 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p53vZ-00089b-9O; Tue, 13 Dec 2022 06:58:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=zJWHE4L2vkzuIYUYWG0/x/CTF5uX6d1RwxbUr0fWo+w=; b=HO2oG9LLWfEk zwWAknkCkw6t7ZxdDb0AhZw36MO48sj6gBn7McgxfLHMaji2nZ6Ua+7zT1XItUjYU/oobR6NhYt/3 QkBy81xyaEd00hAzDZNT0yN1FRZZXzLkKuwe1j44ns/yjsVcOhdnSLsh4DstwGrmb3FDubnZF5hsp FTsxkVrZRO0nQXkm+iEfAxuprCMmJQolZbGK9sctqtZH5Z57TDA0RYePnM5mk9u65y3A3mRM/h1jf RW2Oo8TUXmHZ6NIrlcgC9xBxN/jZP91Yiw++VJH2vN4kJjipEeYDUAsFZX234sNCoqPskRGCa2I9W ILiZuA5VRRAUZgIxWHdLEA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p53vY-0002Ax-NR; Tue, 13 Dec 2022 06:58:29 -0500 In-Reply-To: (message from Gregory Heytings on Mon, 12 Dec 2022 21:28:58 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:250819 Archived-At: > Date: Mon, 12 Dec 2022 21:28:58 +0000 > From: Gregory Heytings > cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, 59347@debbugs.gnu.org > > > >> "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. I don't see it as an important part of the doc string. The purpose of the doc string is not to explain how Emacs finds fonts, it is to explain what's this variable's effect on that. > >> 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. I don't really see what more could I say. I'm talking about face merging, when none of the faces is 'default'. If this is still not enough, please look at the callers of realize_gui_face, and I hope you will see what I mean. > >> 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. Look farther back in history than just 6b1ed2f2c9, and you will see that 6b1ed2f2c9 simply restored the situation which existed until not-so-long before that. It is NOT the change which introduced this issue, it is a change that fixed another issue. So yes, these attributes were "hard" constraints for most of the history of the current display engine. And for good reasons, I might add.