From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#59347: 29.0.50; `:family` face setting ignored Date: Mon, 12 Dec 2022 09:49:28 +0800 Message-ID: <87ilihjsrb.fsf@yahoo.com> References: <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> Reply-To: Po Lu Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26484"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 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 02:50: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 1p4XxS-0006cZ-Co for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Dec 2022 02:50:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4XxE-0003Ga-5Z; Sun, 11 Dec 2022 20:50: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 1p4XxC-0003GM-7o for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 20:50: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 1p4XxB-0003LW-RG for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 20:50:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4XxB-0005v3-NC for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 20:50:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Dec 2022 01:50: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.167080978622741 (code B ref 59347); Mon, 12 Dec 2022 01:50:01 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 12 Dec 2022 01:49:46 +0000 Original-Received: from localhost ([127.0.0.1]:49447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4Xww-0005uj-1z for submit@debbugs.gnu.org; Sun, 11 Dec 2022 20:49:46 -0500 Original-Received: from sonic305-22.consmr.mail.ne1.yahoo.com ([66.163.185.148]:36856) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4Xwu-0005ud-Nb for 59347@debbugs.gnu.org; Sun, 11 Dec 2022 20:49:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670809777; bh=h5fdobi7YBSwVe2y6wTCf+7+L1+F0lC1Ve0n6jrEmBE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=tqGyMIx8HNv1G987rBkfB9cWJPBGiXZh3tywxG9CzF0k/sgUrAl+8IIV0hXofs7/S7ynslT/RQqyphcsy+UARWIHihsOWWjDOXl6Z382AWndJgPJcyh5UibpHUiOUlGyzBtbRnaL8mgzRztCisazaVDluFu83vRbzdcxm1nf9AAVazxOZU9cYImxpUltna0O0LMMXMTSM9Xl8aipHsYOBTyVUGt6aO6s8fhsWUCb1neTt3S7NjKfPRdZRA2X09iwIKJlWOAp0O8SeFv1nJkJFEdrSDuD9IHEYIg/cycrF/ivpR0JNrZb1PAD95UBdavJZTKQDWU/uWtw8fxIa28bMQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670809777; bh=npw6GW/gADWmJwWOTVTIX/ThFK2tityHBhm59KlgGQZ=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=FlIT77xH365mwuBIbKVfLh+nj0opArXjnKCzSzoaFFDYbSITe1ShypQF6k74y9QZgusD0jY10uN5X5z8rbmUm7EZGCMsiAbTKjLS34IisxWNcsMXBgpEX2BsYr+7OziXrhhubCl3XgYzxGmopTgCBiO1L6+S7WD+Isb0FYO+KPbhePw2otCMSOlXkAFDVvk54o3oE9qRyAuDdJ3rPIhkFyB5RppmH0UONCRNnxzuuNzBfekw8vGz5IvIPGqOwWMUO2Sdesdw/3vDohF62u6EsoVMyjHGe7VcG6DXKmPcI+j1knCLhlgqYXkeivoktVtPi/7q5AG+fhA1CA3f625TCQ== X-YMail-OSG: jAFxQCQVM1k4LEwszdFYbIJgBoKByHVRLrLhXfPJkWOiB1d.Nl3FaUSRebCiqoz hFbAUqNglBm8fEqgL247_.c3eT20.12.Ee5TjRu1TDWi0fTsY44HqW3dkvTw0sjeoniP3moICBoc poNI5sru4UdysOxSYk2XRKJ0nD2PV2p7tse4dzU8F8Sn6.ekNzrKQV76.QyYRmK7SmcAcoZJubwG DVGzvpJK_LCs.LHGPyNNQcnJVxFkDnTM.qQfmbneCqyeV3yoTIy3rNVjX4kR6tYnzoDggMOt_dAf SvcLNV_1iFVntvqxuIc1EAMKX3.e4PO2Qzp8tkVYRmsTTxHpCOCf25sJNx8zDOR2bRY6cZwlbELs dm.eihC831lSaiY95PL88I0oO_.U3EUnhtfBsJW8.6kV_IypEEHmW5tuSBWeKJz4u6YVQWI.svQ9 6JsZF8GZyEp8C5VcaaGa9Mst_rhxJ8aYtgL.eixDm86KWTuIqKMkLbcvakm.CnhoSRhh846ap.il D7uuLV63_e2hdMczErr47T8O9vg7hPKrAk_KEuXGdf2fKyzkza7prxUU1IvZWqHE54Zx9TEKzYuH WUgisErPyADCNEnZRHs6rgpjQUtAZmGNBMQQrBym.uZQNHqZOzJVTTmE6hvALMP9ByyKE6huyCxw 6NgamYdTUsD0VwtUXiIn5_VvLFdLgrKKYBKaeFd_rDbtZMqizPNEfYoeTAZnqDWzZg2FWkNocnFI sO6ZTky4HgNzuNT7HsL8swVykGDQeHtThAbekXiAq3KFp.zA6kd7GifTpTXeGPz.3xB4Dwlcv1kn JU.tEiP86JtIKy.eH617eHGl38DrXepCC4F3V.wz2l X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Mon, 12 Dec 2022 01:49:37 +0000 Original-Received: by hermes--production-sg3-b666c6484-prndz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7f74274640c7619e5ab9515455c38369; Mon, 12 Dec 2022 01:49:34 +0000 (UTC) In-Reply-To: (Gregory Heytings's message of "Mon, 12 Dec 2022 00:57:49 +0000") X-Mailer: WebService/1.1.20926 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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:250667 Archived-At: Gregory Heytings writes: > Amazing. I thought this exhausting discussion was over, but no, Po Lu > came and "improved" the code that was agreed upon only a couple of > hours after it was pushed, disregarding this entire discussion, the > docstring of the variable that the commit introduced, the commit > message, and without asking any questions. How can that be right, how > can that be acceptable? I did not change the behavior of that commit at all. That can hardly be called ``disregarding this entire discussion''. > Po Lu's commit said "there is no reason any user should have to think > about bitmasks" even though the docstring said "there is no reason to > change that value except for debugging purposes." (Of course, that > sentence was also removed from the "improved" version of the > docstring.) So are you saying that users are not supposed to debug Emacs? Then let's stop distributing etc/DEBUG, to save cycles when unpacking Emacs! While we're at it, let's also strip Emacs binaries by default. > It is on purpose that that variable was a bitmask and not > a list, it is on purpose that that variable was used in a macro and > not in a function: there is no reason that each face realization in > each Emacs instance should spend unnecessary CPU cycles (a function > call and traversing a list) on a variable that should never (or hardly > ever) be changed, and that was introduced only to help debugging other > potential problems in that subtle area of Emacs' code. And what was the problem with a list? How many cycles is traversing a list? How many time will it take for your CPU to perform everything? Premature optimization is the root of all evil. If you think that is likely to lead to a real performance problem, then you're more or less 60 years out of touch with the performance of modern computer technology. So, please, demonstrate that searching for a symbol through a list with 3 elements leads to a performance problem. Can you find any other ``debug variable'' that is a bitmask? What if we add different font spec attributes in the future, that bump the index past 29 bits? And why should Lisp have to know about bitmasks at all? > The name of the variable was changed, and the docstring was > "improved", and became completely wrong. It is simply untrue that > this is a list of attributes that Emacs will "ignore when realizing a > face", or in fact that this changes anything fundamental in the way > Emacs realizes faces. Then I guess you only read the first sentence of the doc string. Read it again, specifically: tells Emacs to ignore the `:weight', `:slant' and `:width' face attributes when searching for a font and an exact match could not be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ found for the font attributes specified in the face being realized. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What is inaccurate about that statement? Unlike your doc string, it does not need the caller to know about the inner workings of the face code (how many of our users even know about the function realize_gui_face?) But anyway if you respond with some more nonsense, don't expect me to reply. Please demonstrate: - There is a real performance problem with searching through a list with three elements upon face realization. - My change actually changes the behavior of the variable, leading to this bug not being fixed.