bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces.

[Eli Zaretskii <eliz@gnu.org>]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 7 Dec 2024 07:28:33 -0600
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, trevor.m.murphy@gmail.com, me@eshelyaron.com, 
> 	73862@debbugs.gnu.org
> 
> On Sat, Dec 07, 2024 at 1:50 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > If we do prefer to support remapping mode-line and header-line faces, then
> > I can suggest the semi-kludgey "fix" below. Is this better than what we
> > have now?
> 
> Does this patch make it so that remaps are considered for header-line even
> if header-line-active no longer inherits from header-line?

It shouldn't.  If you apply it and see something like that, it should
be considered a bug somewhere (but I would be very surprised if it did
happen).

All this change does it give the code the chance to account for
remapping of header-line-active if header-line was remapped.  But if
the latter doesn't inherit from the former, that chance will not
produce anything that depends on header-line's remapping.

> The more I think about this, the less
> inclined I'd be to play special case whack-a-mole with it and the more I'd
> be inclined to either "live with it" or figure out a way to disable
> remapping entirely in certain rendering contexts.

Disabling remapping entirely is not feasible, since too many places
already account for remapping.

> Tab bar mode is another one that comes to mind that probably
> shouldn't use remaps at all when rendering.

Why not?