GNU bug report logs - #53636
29.0.50; face-remapping broken on master

Previous Next

Full log

Message #31 received at 53636 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: larsi <at> gnus.org
Cc: 53636 <at> debbugs.gnu.org, tsdh <at> gnu.org
Subject: Re: bug#53636: 29.0.50; face-remapping broken on master
Date: Mon, 31 Jan 2022 21:44:45 +0200

> Date: Mon, 31 Jan 2022 14:20:01 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 53636 <at> debbugs.gnu.org, tsdh <at> gnu.org
> 
> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Cc: 53636 <at> debbugs.gnu.org,  tsdh <at> gnu.org
> > Date: Sun, 30 Jan 2022 21:28:53 +0100
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > > Do we still need the mode-line as a parent of these two faces, or can
> > > we go back to what we had before the variable-pitch mode-line changes?
> > 
> > The plan is to reintroduce the variable-pitch stuff after we've ironed
> > out the width issues, so I'd rather keep the faces as is.  (And I think
> > it makes more sense conceptually, since `mode-line' is also used as the
> > parent of other faces, like `header-line'.)
> 
> OK, I will see what I can do.

Basically, the problem is that mode-line is a well-known face name,
and so it can be expected that user customizations and Lisp packages
rely on the fact that remapping or otherwise tweaking that face
directly affects the display of the mode line of the selected window.

So when we effectively renamed mode-line to mode-line-active, we broke
compatibility, since in some situations, such as the one described
here, what was previously done with the mode-line face must now be
done with mode-line-active face.

Is that analysis correct, or am I missing something?

If so, my suggestion is:

  . rename mode-line-active back to mode-line
  . introduce a new face, mode-line-base, say, from which mode-line
    will inherit, like mode-line-active now inherits from mode-line

Then all the tricks people play with the mode-line face will work
again, and we can warn not to rely on remapping mode-line-base to
automatically affect the mode lines of the currently selected frame.
Since this is a new face, we don't need to worry about code out there
which already remaps that face.  But making this new mode-line-base
face use variable-pitch, for example, will still produce the same
effect that we had with mode-line a few weeks before.

Would that be an acceptable solution?  (I considered alternatives, but
they are all uglier.  Basically, the "basic faces" aren't supposed to
inherit from other faces, for face remapping to work as expected.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.