bug#53636: 29.0.50; face-remapping broken on master

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 53636@debbugs.gnu.org,  tsdh@gnu.org
> Date: Mon, 07 Feb 2022 00:16:08 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> The bug I'm talking about here is that `face-remap-add-relative' is
> supposed to be buffer-local, but calling it, and then creating a new
> frame (with point in that buffer) will have the remapping take place in
> all buffer in the new frame.

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?

> >> 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?
> 
> 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"?