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#53636: 29.0.50; face-remapping broken on master Date: Sat, 12 Feb 2022 14:20:11 +0200 Message-ID: <83a6ews2dg.fsf@gnu.org> References: <87o83tib13.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.org> <83mtj85tm1.fsf@gnu.org> <87wnibn48c.fsf@gnus.org> <8335kz4tgu.fsf@gnu.org> <87ee4hg7g6.fsf@gnus.org> <83y22p21na.fsf@gnu.org> <871r0haqzr.fsf@gnus.org> <8335kw1n9u.fsf@gnu.org> <87mtj34mdj.fsf@gnus.org> <837da6yb0j.fsf@gnu.org> <87k0e5vqjm.fsf@gnus.org> <83o83hwngw.fsf@gnu.org> <87leykpiy0.fsf@gnus.org> <83sfssuoqt.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18358"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53636@debbugs.gnu.org, tsdh@gnu.org To: larsi@gnus.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 12 13:21:10 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 1nIrOo-0004fN-0O for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 12 Feb 2022 13:21:10 +0100 Original-Received: from localhost ([::1]:40176 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nIrOm-00034i-Ud for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 12 Feb 2022 07:21:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41422) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIrOg-00033H-7v for bug-gnu-emacs@gnu.org; Sat, 12 Feb 2022 07:21:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39781) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nIrOf-0005zH-U3 for bug-gnu-emacs@gnu.org; Sat, 12 Feb 2022 07:21:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nIrOf-0002rf-RC for bug-gnu-emacs@gnu.org; Sat, 12 Feb 2022 07:21: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: Sat, 12 Feb 2022 12:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.164466842510954 (code B ref 53636); Sat, 12 Feb 2022 12:21:01 +0000 Original-Received: (at 53636) by debbugs.gnu.org; 12 Feb 2022 12:20:25 +0000 Original-Received: from localhost ([127.0.0.1]:33676 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nIrO5-0002qb-D8 for submit@debbugs.gnu.org; Sat, 12 Feb 2022 07:20:25 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nIrO4-0002qQ-7q for 53636@debbugs.gnu.org; Sat, 12 Feb 2022 07:20:24 -0500 Original-Received: from [2001:470:142:3::e] (port=38246 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIrNy-0005pl-Tz; Sat, 12 Feb 2022 07:20:18 -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=4hDOZ7P6NXB6GotbccqgJGO+bosxgG8Gg1Rh23kuJ4A=; b=lUYmeVHDW1I6 uTBcviJjlk3m8/vF3HeGRM4xWTawMq3BNKwfuRMLYAYJU3NwssDcAwCJ/qvUtMuOCbnzJnM7ni1LK nXVgIp+bNi55z+QYYpJUkUziB9B7ojcNUTuy3J0H/jBhtdJhZRniQ5bNcoNKYxUAR7AusD4RKP4kj P6FHdgPHOdyU0FoDef2KmarpPOdog11QjsGiyMT31QzIcB1WIcF+7mCB/sEH2RBzxcuxUPQeIATG2 3gFeukbqPjqmtiPegBdtgEsW0GbAF7URGNATv8bx6+Na8tF1zkmeXmMh/uHfnrIigWmQXHfkdv5L/ noZX4b14bziAUAfVGnq+pA==; Original-Received: from [87.69.77.57] (port=3441 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 1nIrNy-0000pT-BB; Sat, 12 Feb 2022 07:20:18 -0500 In-Reply-To: <83sfssuoqt.fsf@gnu.org> (message from Eli Zaretskii on Wed, 09 Feb 2022 15:57:14 +0200) 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" Xref: news.gmane.io gmane.emacs.bugs:226722 Archived-At: > Date: Wed, 09 Feb 2022 15:57:14 +0200 > From: Eli Zaretskii > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > > > From: Lars Ingebrigtsen > > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > > Date: Wed, 09 Feb 2022 09:01:27 +0100 > > > > Eli Zaretskii writes: > > > > > So: in the scenario you've shown, do we want *scratch* to have its > > > mode-line remapped on the new frame, or don't we? IOW, I agree that > > > the result ideally shouldn't depend on the buffer where make-frame is > > > called, but I need to know what is the desired behavior in order to > > > find code which produces the undesired results. > > > > Yes, I don't think that the results in the new frame should depend on > > the current buffer when `make-frame' is called. > > OK, I think I know where this happens. Let me dig a bit. After digging into this, I'm sorry to say that this is unworkable: if a basic face inherits from some other face, and that other face is remapped via a buffer-local value of face-remapping-alist, the result will be unpredictable. For a simple demonstration of the unpredictable nature of the result, try this simple variation of your recipe, which just adds the last step: . emacs -Q . M-: (progn (face-remap-add-relative 'mode-line 'link-visited) (make-frame)) RET . C-x C-f src/xdisp.c RET Now all the buffers on the new frame have the mode line rendered with the default attributes, whereas all the buffers on the old frame suddenly get the mode line rendered with the link-visited face. IOW, just visiting a file on the new frame causes the mode line to be displayed differently than it was before you visit that file. This is due to how we handle the basic faces. There's "face realization" and "face look up". The former means we recompute all the face's attributes and load the necessary GUI resources (colors, fonts, etc.) from scratch; the latter means we just look up in the frame's face cache the attributes that were already computed. Face realization is obviously much more expensive than look up, so we only realize the basic faces when the frame's face cache is empty. A new frame has its cache empty, but there are other situations when the face cache could become empty: for example, when attributes of a named face change. So fundamentally, whether using a basic face will go through "face realization" or just "face look up" is unpredictable and can happen at any moment. Here is the crucial point: face inheritance is only considered in "face realization", not in "face look up". (That is why we empty the face cache when a named face is modified in the first place.) So if a basic face inherits from another face, and that other face is remapped, the effect of the remapping will make the result of "face realization" different from "face look up", although no face has changed the attributes. And since it is unpredictable when Emacs will use "face realization" and when it will settle with "face look up", you get unpredictable results. Moreover, Emacs expects a remapped face to have a different face ID internally (the ID is just the index of the remapped face in the frame's face cache). But "face realization" when a parent face is remapped doesn't yield a new face ID, it just influences the attributes recorded under the original face ID. The bottom line is that if "face realization" is called when the current buffer happens to be one with non-nil face-remapping-alist, the default face ID will use the attributes of the remapped face, but Emacs will not know that the face was effectively remapped. And that is the root cause of what you see in your recipes. Contrast this with a perfectly correct and expected behavior with these slightly modified recipes: (progn (face-remap-add-relative 'mode-line-active 'link-visited) (make-frame)) (progn (face-remap-add-relative 'mode-line-active 'link-visited) (switch-to-buffer "*Messages*") (make-frame)) Now the only mode line that is affected is the one of the *scratch* buffer (when it is the current buffer), no matter how many other files you visit after creating the new frame, and no matter which frame displays what buffer. So I can just reiterate what I said up-thread: basic faces cannot inherit from other faces, if we want to support remapping of those parent faces. Our internal infrastructure for handling the basic faces simply doesn't support this.