From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuri D'Elia Newsgroups: gmane.emacs.devel Subject: Re: Incorrect font weight selected Date: Wed, 05 Jan 2022 18:11:50 +0100 Message-ID: <87r19mulkg.fsf@wavexx.thregr.org> References: <87pmpv708h.fsf@wavexx.thregr.org> <83r1abcb93.fsf@gnu.org> <87y24jqahr.fsf@wavexx.thregr.org> <83ilvnc6z4.fsf@gnu.org> <875yrmyk8q.fsf@wavexx.thregr.org> <87y24grwp6.fsf@wavexx.thregr.org> <877dbzo98z.fsf@gnus.org> <83bl1b12b5.fsf@gnu.org> <837dbz112w.fsf@gnu.org> <71a9cd97-02a6-79d7-6af8-b4aef3d1baa8@yandex.ru> <83y24eyww3.fsf@gnu.org> <87wnjyt9yd.fsf@wavexx.thregr.org> <83sfumyr9c.fsf@gnu.org> <877dbe86tv.fsf@wavexx.thregr.org> <83ee5m9kp7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9106"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.5; emacs 29.0.50 Cc: larsi@gnus.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 05 18:42:45 2022 Return-path: Envelope-to: ged-emacs-devel@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 1n5AJ6-00025g-C2 for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Jan 2022 18:42:40 +0100 Original-Received: from localhost ([::1]:35482 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5AJ4-0005Y9-Hm for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Jan 2022 12:42:38 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58560) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5AIE-00044J-Ob for emacs-devel@gnu.org; Wed, 05 Jan 2022 12:41:48 -0500 Original-Received: from [2001:41c9:1:41f::63] (port=33314 helo=erc.thregr.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5AIC-0004Ou-6r; Wed, 05 Jan 2022 12:41:45 -0500 Original-Received: from [193.106.183.18] (helo=localhost) by erc.thregr.org with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1n5AIG-001pVJ-EI (envelope-from ); Wed, 05 Jan 2022 18:41:48 +0100 In-reply-to: <83ee5m9kp7.fsf@gnu.org> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:41c9:1:41f::63 (failed) Received-SPF: pass client-ip=2001:41c9:1:41f::63; envelope-from=wavexx@thregr.org; helo=erc.thregr.org X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:284259 Archived-At: On Wed, Jan 05 2022, Eli Zaretskii wrote: > Thanks, but this is a scary change. I have no idea what unintended > consequences it could cause. At least on X11, I've tried creating frames both normally, using the daemon (across x11 and terminal sessions), and generally I've been using this for about a week. > Can we back up a bit, and understand how the change in 1b2511f > triggered the problems you see? If you already understand that, can > you describe it? Maybe we could then come up with a safer, better > understood change. If nothing better comes to mind, I'd prefer to > revert 1b2511f than doing something like what you propose. Overall, the change in 1b2511f seems correct to me. font_list_entities (and the downstream font_delete_unmatched as touched by 1b2511f) can return a list of candidates which can be used subsequently for refinement. If you look at the main font_find_for_lface which is where the action takes place, this is done by using font_list_entities first, then using font_select_entity to narrow it down further. This works as intended already, and that's why the problem only showed itself on new frames and/or with the daemon (which doesn't immediately create a frame). When creating a new frame though, the attributes do not come from the existing face spec the user supplied, but are are reconstructed from the full font name that matched in the first frame instead. I wrote above my guess about why this seems to be done in this way. We could probably do better by re-using the attributes in the frame that called make-frame (if that frame is of the same type as the new frame), but that requires a bit more work. So in the end we're left with font_open_by_name, which is passed a fully qualified font pattern/name, parses it, but then resets the attributes for selection, discarding the font attributes as set by the user. It used to work as the returned entities only matched the requested font exactly, so no selection ever took place. The original commit introducing font_open_by_name also has the attribute override, so that commit doesn't really tell me much about it. Maybe font_list_entities never returned multiple weights/slants as we're doing now, so the problem went unnoticed for a long time. Or something else I don't see in the other font backends. Still, I do support the change in 1b2511f despite the breakage. I'd rather fight with the breakage introduced by this change.