GNU bug report logs - #53636
29.0.50; face-remapping broken on master

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 53636 <at> debbugs.gnu.org, tsdh <at> gnu.org
Subject: bug#53636: 29.0.50; face-remapping broken on master
Date: Sun, 06 Feb 2022 09:12:45 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 53636 <at> debbugs.gnu.org,  tsdh <at> gnu.org
> Date: Sat, 05 Feb 2022 23:27:36 +0100
> 
> (progn
>   (face-remap-add-relative 'mode-line 'link-visited)
>   (make-frame))
> 
> vs
> 
> (progn
>   (face-remap-add-relative 'mode-line 'link-visited)
>   (switch-to-buffer "*Messages*")
>   (make-frame))
> 
> In the first case, the new frame will have mode-line remapped to
> link-visited in all windows, while in the latter it won't.  So it looks
> like a pretty simple bug -- `make-frame' (when computing the faces for
> the new frame) is using the buffer-local value of
> `face-remapping-alist' instead of the global one.

But which case is considered a bug?  In the first case, the mode line
of *scratch* is affected in the second frame; in the second case the
remapping doesn't show in that buffer on _any_ frame, although
face-remapping-alist is updated.

> But after poking at the code for a couple minutes, I'm not sure where
> the computation for faces is done for new faces.  Hm...  is it
> `face-spec-recalc'?  Hm...  but that doesn't access
> `face-remapping-alist'...   Is this done at a lower level?

What is "this" and "the computation" which you are asking about here?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.