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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org
> Date: Thu, 05 Dec 2024 22:42:58 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> We could perhaps add special-purpose code that would consider face
> inheritance for mode-line and header-line faces when remapping them,
> but that would get is in a different mess:
> 
>  . mode-line-inactive inherits from mode-line only by default, on
>    color displays it doesn't; so if you remap mode-line,
>    mode-line-inactive will only be affected on monochrome displays
>  . header-line also inherits from mode-line, albeit only by default,
>    so remapping mode-line would _sometimes_ affect header-line (and
>    also header-line-active and header-line-inactive) and sometimes not
>  . if the user customizes some of the mode-line or header-line faces
>    to not inherit or to always inherit, remapping mode-line or
>    header-line will produce different results for different faces
> 
> So basically it's a royal mess, all of it caused by the fact that
> people somehow expect that remapping the header-line face will affect
> header-line-active and header-line-inactive, and similarly for
> mode-line.  That was never supported for basic faces, and I think it
> makes little sense to support it in the future, because the results
> will certainly surprise someone.
> 
> So I tend to close this bug as wontfix, and just mention in the
> documentation (NEWS at least) that people who remap header-line or
> mode-line need now to remap the new -active and -inactive faces.

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?

Note that it immediately reveals the problems I mentioned above.  For
example, if you remap header-line, both header-line-active and
header-line-inactive immediately follow suit, but if you remap
mode-line, only mode-line-active follows, whereas mode-line-inactive
only follows on TTY frames (because all other frames support :box).
So if we install this, we should probably change the definition of
mode-line-inactive in some way?

Stefan, any suggestions or comments?

diff --git a/src/xfaces.c b/src/xfaces.c
index f626480..9704c05 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -5144,6 +5144,19 @@ lookup_basic_face (struct window *w, struct frame *f, int face_id)
      for the very common no-remapping case.  */
   mapping = assq_no_quit (name, Vface_remapping_alist);
   if (NILP (mapping))
+    {
+      /* Special treatment for mode-line and header-line faces, for
+	 backward compatibility: people might remap 'mode-line' and
+	 'header-line' faces and expect the *-active and *-inactive
+	 faces to change accordingly.  */
+      if (face_id == MODE_LINE_ACTIVE_FACE_ID
+	  || face_id == MODE_LINE_INACTIVE_FACE_ID)
+	mapping = assq_no_quit (Qmode_line, Vface_remapping_alist);
+      else if (face_id == HEADER_LINE_ACTIVE_FACE_ID
+	       || face_id == HEADER_LINE_INACTIVE_FACE_ID)
+	mapping = assq_no_quit (Qheader_line, Vface_remapping_alist);
+    }
+  if (NILP (mapping))
     return face_id;		/* Give up.  */
 
   /* If there is a remapping entry, lookup the face using NAME, which will
@@ -7447,6 +7460,7 @@ syms_of_xfaces (void)
   DEFSYM (Qcursor, "cursor");
   DEFSYM (Qborder, "border");
   DEFSYM (Qmouse, "mouse");
+  /* Qmode_line is defined in keyboard.c  */
   DEFSYM (Qmode_line_inactive, "mode-line-inactive");
   DEFSYM (Qmode_line_active, "mode-line-active");
   DEFSYM (Qvertical_border, "vertical-border");