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

Previous Next

Full log

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

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: Re: bug#53636: 29.0.50; face-remapping broken on master
Date: Tue, 08 Feb 2022 14:29:35 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 53636 <at> debbugs.gnu.org,  tsdh <at> gnu.org
> Date: Tue, 08 Feb 2022 07:08:29 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > And what happens when you call make-frame from another buffer is not a
> > bug?  Is face-remapping-alist supposed to affect the buffer in which
> > it is set on all frames or just on the single frame where
> > face-remap-add-relative was called?
> 
> I'm not sure.  But the current behaviour (affecting all buffers on the
> new frame) has to be a bug.
> 
> >> The computation of the faces for the new frame.
> >
> > You mean init_frame_faces, which calls realize_basic_faces?  Or do you
> > mean some other kind of "face computation"?
> 
> I don't know?  I'm looking for the code that leads to the behaviour I
> described.

We need to agree on what "this behavior" is.  Or at least I need to
understand what you mean by that, in order to be able to provide
information that could help you.

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.

Previous Next

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