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: Mon, 12 Dec 2022 19:10:56 +0200 Message-ID: <83o7s8r1i7.fsf@gnu.org> References: <83tu2t4ie9.fsf@gnu.org> <7cc9e03786e324ff82ef@heytings.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21943"; 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 Mon Dec 12 18:12:15 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 1p4mLd-0005Km-2Y for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Dec 2022 18:12:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4mLT-0008Po-O8; Mon, 12 Dec 2022 12:12:03 -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 1p4mLT-0008PM-2k for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 12:12: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 1p4mLS-0007d2-QT for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 12:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4mLS-00014e-B9 for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 12:12: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: Mon, 12 Dec 2022 17:12: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.16708650634100 (code B ref 59347); Mon, 12 Dec 2022 17:12:02 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 12 Dec 2022 17:11:03 +0000 Original-Received: from localhost ([127.0.0.1]:54166 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4mKV-000144-CM for submit@debbugs.gnu.org; Mon, 12 Dec 2022 12:11:03 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4mKT-00013d-AX for 59347@debbugs.gnu.org; Mon, 12 Dec 2022 12:11:02 -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 1p4mKN-0007MB-7K; Mon, 12 Dec 2022 12:10:55 -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=D3LAd1AY1wc/fe0tUDnlAf5dejzCX96jXU5dOTDCUig=; b=KShbXNaJbnQ9 5KIh5+VUyYBeNtIe+LZGqHr9tpZm9KG66GleKy7GYKg62Xfx0wWuQ3xKdzFxZ4TmVX2zsdGJqRBxP o1UZ2GSj3hZ3omscxWSqACblpouZe4v4A77VnznrVFZj1Looz1njmiEJSR/1CoGnVaN0unCVjPPo3 H9m8w3wsJJzv64c6KVL7TvHqlRfdaKFGDNDCHDHQcdWYuxYKXruiMnpUF0AyvYMp/toWsPE+5PI3m m6jPbEHiqG+vK3iCtn2OYKZ+r0XdbNmaUaD9SCrgh8KEoCYIO1oWI5770T5+MLNIV5jW0sLb/b8s6 vCxDYAP4f7IK0NumcQQ7LQ==; 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 1p4mKM-0007ga-HW; Mon, 12 Dec 2022 12:10:54 -0500 In-Reply-To: (message from Gregory Heytings on Mon, 12 Dec 2022 16:12:22 +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:250724 Archived-At: > Date: Mon, 12 Dec 2022 16:12:22 +0000 > From: Gregory Heytings > cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, 59347@debbugs.gnu.org > > 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. > 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. > 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"? > This was also important: > > "There is no reason to change that value except for debugging purposes." I will add something like that. > > 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. OK, thanks. > 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. I wouldn't invest more energy in this at this point, since we don't yet know whether it is needed and how badly. Our hope, after all, is that no one will ever need to change the default value of this variable. From that perspective, inventing fancy functions to make it easier to customize a bitmap is overkill.