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: Sun, 04 Dec 2022 16:21:46 +0200 Message-ID: <83tu2b9rlx.fsf@gnu.org> References: <834juu9aya.fsf@gnu.org> <7cc9e03786024fc72f3b@heytings.org> <83a64l65ai.fsf@gnu.org> <7cc9e0378678a092e6ee@heytings.org> <835yf962q4.fsf@gnu.org> <7cc9e03786754c9e0aaf@heytings.org> <83zgcl4jra.fsf@gnu.org> <7cc9e03786c281cffdd4@heytings.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32985"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 Sun Dec 04 15:23:19 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 1p1ptm-0008QR-Rx for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 04 Dec 2022 15:23:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p1ptX-0008If-Or; Sun, 04 Dec 2022 09:23: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 1p1ptW-0008IJ-BT for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2022 09:23:02 -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 1p1ptW-0000iB-39 for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2022 09:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p1ptV-0000Hb-VS for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2022 09:23:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Dec 2022 14:23: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.16701637361052 (code B ref 59347); Sun, 04 Dec 2022 14:23:01 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 4 Dec 2022 14:22:16 +0000 Original-Received: from localhost ([127.0.0.1]:57965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1psm-0000Gu-45 for submit@debbugs.gnu.org; Sun, 04 Dec 2022 09:22:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1psj-0000Gj-A3 for 59347@debbugs.gnu.org; Sun, 04 Dec 2022 09:22:14 -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 1p1psd-0000aB-4s; Sun, 04 Dec 2022 09:22:07 -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=JFZzyEDGX58BieRysdx4K1tMHZBnDYhMbMMt2JhDhJA=; b=VKMRwZEZlxQK Q37l7W0vzV7J7vjFZgZMEEGmNPQR1bHWslHknSzVCtoyix96HnYgPBy6Zbn6QigUM91O76Wz/1trU 0yKZDw2SW/K4ATPnFMe0z7H3Ovp2ZA0dGfSulzqb9Yxl32H2wwg6HNvOvAj+ay1Kld9nimhS0c1Gr rL432RQP9Ds3hSW98u0RYM6xEUJ/VnyDLSa3PGvcTiX/3f/iROBH/PjqSpCbOzXrwvCOmgaIdM/OE utT8R4OGxy6qdj8aVn1wBMzrExHtn+NjemhRgSPxKVNlgKrEU74iGhTVnYkwyhvLFmzozeGZvOGO0 5kCxfaKhup2vJ0XfDtMgXg==; 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 1p1psc-0006Xp-M7; Sun, 04 Dec 2022 09:22:06 -0500 In-Reply-To: (message from Gregory Heytings on Wed, 30 Nov 2022 15:38:37 +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:249944 Archived-At: > Date: Wed, 30 Nov 2022 15:38:37 +0000 > From: Gregory Heytings > cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org > > I attach a screenshot of the font preference box in Firefox. In that > screenshot you see the three most general font families: Serif, Sans Serif > and Monospace. The Serif and Sans Serif families are meant for variable > pitch fonts. Emacs uses these same "Sans Serif" and "Monospace" families. Emacs uses the same families because we have it in face-font-family-alternatives, and/or because Fontconfig has the same notion of families. There's no magic here, and btw face-font-family-alternatives can be customized by the user to yield completely different preferences. But nothing in the family name tells Emacs it _must_ produce a variable-pitch font. Those are just lists of font names, that's all. In your example, you consider DejaVu Sans to be a proper font for that family, but the name "DejaVu Sans" doesn't appear anywhere, so why is it correct? > > You asked for ultra-heavy and heavy weight, but got bold -- why is that > > TRT? > > Same answer: it is TRT because the "family = Sans Serif" specification of > the variable-pitch face is obeyed. This doesn't make sense to me: why should Emacs obey "family = Sans Serif", but not "weight = ultra"? > > Why is it "clear" that font selection should do what you expect here, > > given that the only (weak) indication that we are after a variable-pitch > > font is the family? Why do you consider it so preposterous that Emacs > > comes up with a semi-bold font, when you ask for a semi-bold font? > > > > You seem to misunderstand how font selection works. Stop right there. If you still wonder how you got a semi-angry response in the dispute about narrowed-locking, this arrogant attitude is the reason. You are always right and anyone who disagrees "doesn't understand". You are dangerously close to getting the same reaction in this discussion. If you want a rational, technical, efficient discussion, please drop the attitude and start leveling with me. Do not try to tell me what I do and don't understand, and do not reply with arrogant responses like this one: > > How do you know it wasn't considered? > > I debugged the code. Instead, please assume that I know enough about the code to have good reasons for asking my questions, and please humor me with full, detailed responses. That is the only way to convince me that you are right. So once again, here are my questions: . why do you think Emacs must return only variable-pitch fonts for a spec that includes family = Sans Serif"? where and how should Emacs get the indication that only variable-pitch fonts are acceptable in that case? . why do you consider the family attribute of a face be more important than other attributes? if not all the attributes of a spec are "equal" in their importance, which attributes are more important, and why? and if bold is fine when semi-bold was requested, what about other weights, like ultra-light -- are they also okay? if not, why not? what are the criteria here and with other similar attributes? Without getting detailed answers to these questions, I don't see how we can continue the discussion, nor why we should; and there's no real reason for me to change my mind that what Emacs does now with these specs is correct and expected. > There are, on my system, no less than 166 fonts in the "Sans Serif" > family. It just happens that none of them explicitly supports the 'heavy' > weight / has no explicit 'heavy' variant. But that is not a sufficient > reason to reject all those 166 fonts. What Emacs should do, what others > programs do, and what Emacs would do with the patch, is to select the best > possible font among those 166 fonts. That would mean the user cannot specify a weight meaning "give me that weight or admit failure to find a suitable font". And how does that make sense? > I don't know what else I could say to convince you. You could start showing data and details of the code workings, instead of talking slogans and insults.