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: Wed, 02 Feb 2022 20:48:42 +0100
> 
> >> OK, you want to change the header-line and mode-line-inactive faces so
> >> that they no longer inherit from the mode-line face?
> >
> > Yes, I think this is the best way forward.  Though it will be somewhat
> > backward-incompatible, if someone customizes mode-line and expects
> > header-line to follow suit.
> 
> I think this would break a lot more than the current situation does.

Yes, it will.  But if we want to break the link between mode-line and
header-line, I see no better way.

> Lots of people expect these faces to inherit the way they do, and have
> set up stuff based on that.  Programmatic remapping of the `mode-line'
> face, on the other hand, is a much smaller issue, and we can just say
> "use `mode-line-active' instead".

That'd be fine with meas well,if it's acceptable.

> Note that in the other frame (displaying *Messages*), the
> mode-line-inactive face has inherited the underline from line-visited.
> (If I select that window, then the mode-line face has not, that is just
> in the current buffer.)  So remapping a face that has inherited faces
> leads to side effects in other places...

When you remap a face, the faces that inherit from it are affected
only on new frames, because when we create a frame, we recompute the
set of the basic faces for it from scratch and thoroughly.  That's
exactly the other side of the issue which started this discussion: the
inheriting faces on the original frame aren't affected by the
remapping of the parent face, but those same faces on new frames are.

> Anyway, what I was thinking of is a really simple solution: Have
> `face-remap-add-relative' loop over all children and remap them, too.
> (I haven't actually attempted to write something like that, though.  😀)

Why not leave this to the (small number of) applications that want to
do this?