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

[Eli Zaretskii]

> Date: Tue, 8 Feb 2022 19:24:19 +0100
> Cc: larsi@gnus.org, 53636@debbugs.gnu.org, tsdh@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  >> Face remapping has never been properly synchronized with windows and
>  >> frames.  What's needed is a simple hierarchy window > window's buffer >
>  >> window's frame where the first should be implemented with the help of a
>  >> 'face-remapping' window parameter and the last with the help of a
>  >> 'face-remapping' frame parameter.  Just like we (should) do for things
>  >> like the scroll bars or fringes.  But we need a consensus on this first.
>  >
>  > I don't think I understand this remark.  While what you describe might
>  > be a useful addition, I don't see why we must have it, or else.
>  > Surely, Emacs has gobs of features that depend only on the buffer, but
>  > not on the window nor the frame where that buffer is displayed?  Why
>  > cannot we have a reasonable behavior with face-remapping-alist being
>  > specific to a buffer, no matter in what window we display it?
> 
> What makes you think that this is not part of my proposal?  What I mean
> is to have a clear rule how, for example, a buffer local setting of
> 'face-remapping-alist' may affect the creation of a new frame and the
> display of buffers in it.

OK, then we need first to agree on what is the reasonable expected
behavior in such cases.