From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#59347: 29.0.50; `:family` face setting ignored Date: Mon, 12 Dec 2022 21:28:58 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21452"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, 59347@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 12 22:30:29 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 1p4qNZ-0005QO-9s for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Dec 2022 22:30:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4qNA-0003TP-Md; Mon, 12 Dec 2022 16:30:04 -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 1p4qN9-0003T0-8S for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 16:30:03 -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 1p4qN8-0003KA-Nz for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 16:30:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4qN8-0004Ky-7P for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 16:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Dec 2022 21:30:02 +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.167088054216638 (code B ref 59347); Mon, 12 Dec 2022 21:30:02 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 12 Dec 2022 21:29:02 +0000 Original-Received: from localhost ([127.0.0.1]:55520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4qM9-0004K4-PH for submit@debbugs.gnu.org; Mon, 12 Dec 2022 16:29:02 -0500 Original-Received: from heytings.org ([95.142.160.155]:55394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4qM8-0004Jv-KH for 59347@debbugs.gnu.org; Mon, 12 Dec 2022 16:29:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1670880539; bh=Idd6iJVVCinbaYgavYHV1+dsma3Qv5BZ2UrPA9AUgXc=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=tSNS4rySFdXV37ZAi1NyzmcpVhM3V0tGKoHPtfhK2Sc8CzBdfQ26NZQ7FG9Mq7N4Q DCiwE12efmAc3QcH99Mvs4DDSfUL9NTlAiKO+pKnBtLscyUnMnvrIQx1PGPMbbZ4dp QNA18lcezK8+I/4euOQlvRxymeXJCMvcs9FldJXCpocWUAE+wWCFLB2uBgZzd1QkRb VZYX55pe3IdEQ92VYUBNsKaVKI3cgjaFQSzBIy0+pvq9om4z6JVNOvrzsHjgrl510z x6+muvF3UejwTj82ce0Ce3wDMf7pr5rMnVRJdUqeC9U/+CWDqev/l4xCwC9D5gtXVA 3O67BBxBayp0A== In-Reply-To: <83o7s8r1i7.fsf@gnu.org> 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:250754 Archived-At: >> 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.