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

Previous Next

Full log

Message #22 received at 53636 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: larsi <at> gnus.org
Cc: 53636 <at> debbugs.gnu.org, tsdh <at> gnu.org
Subject: Re: bug#53636: 29.0.50; face-remapping broken on master
Date: Sun, 30 Jan 2022 22:25:02 +0200

> Date: Sun, 30 Jan 2022 21:19:17 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 53636 <at> debbugs.gnu.org, tsdh <at> gnu.org
> 
> > I'm not sure whether that's a bug or not?  (That remapping a parent face
> > has no effect.)
> 
> But it does have effect.  Try "C-x 5 b *scratch* RET" after evaluating
> the first face-remap-add-relative, and you will see that it does have
> effect.  So it's something more subtle...
> 
> And yes, I think the extra indirection we now have on master exposed a
> problem we never saw before.

Actually, I think this is a new problem on master, introduced by
making the mode-line face be a parent of mode-line-active and
mode-line-inactive faces.  When that was done, lookup_basic_face was
changed to use mode-line-active instead of mode-line, so now the
mode-line face is not recomputed when face-remapping-alist is changed.
Instead, we recompute mode-line-active and mode-line-inactive, but
those are not in face-remapping-alist in this scenario, so they don't
change on the existing frame.

Do we still need the mode-line as a parent of these two faces, or can
we go back to what we had before the variable-pitch mode-line changes?

Previous Next

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