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

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Wed, 4 Dec 2024 23:29:32 -0800
> Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org
> 
>  Furthermore, this problem only happens *once* per Emacs session. After that, 
> I cannot seem to
>  reproduce it again until I restart Emacs. All of this points to a bug, in my 
> opinion unless header-line is
>  considered deprecated or somehow falls into a realm of not being able to 
> remap for some reason. 
> 
> This may be obvious to you all, and me going much further probably isn't 
> realistic, but I am curious if there's
> a problem in the resolving of inherited remapped faces while changing 
> windows. Specifically that it appears
> to use the lack of remap in the newly created window to resolve the remap in 
> the original window. The
> remapping of the active/inactive faces happens explicitly inside 
> display_mode_line / init_iterator with an
> explicit window reference. I don't know enough to know where the inherited 
> faces get remapped, but if the
> window used to remap them is incorrect (because it's the current window, 
> rather than the window the
> mode/header line is being drawn in), I could see there being the issue we're 
> observing.
> 
> Not sure if that helps, but that's as far as I was able to get in my 
> investigation so far.

Once again, please show some simple Lisp to reproduce the phenomena
you are observing.  It is hard to discuss these highly technical
issues on this abstract level.

On the very basic level of the display code, when a display iterator
is initialized, the window for whose display the iterator is used must
be given to init_iterator as its argument, and the buffer of that
window must be temporarily made to be the current buffer.  So this
cannot be the problem in this case.  If init_iterator would be passed
an incorrect window, we'd have much more grave display problems than
this minor issue.