bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#53636: 29.0.50; face-remapping broken on master


From: Lars Ingebrigtsen
Subject: bug#53636: 29.0.50; face-remapping broken on master
Date: Tue, 01 Feb 2022 20:38:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

> 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.

But this is a bug, I think?  You can see the same effect in Emacs 28 if
you do:

(face-remap-add-relative 'mode-line 'link-visited)

This won't have the expected effect on faces that inherit from mode-line
(line mode-line-inactive/header-line) in the current frame, but if you
open a new frame, it'll have an effect there.

> 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

The new mode-line-active face was supposed to fix the decoupling of
mode-line and header-line.  In Emacs 28, there's no way to change the
look of the (active) mode line without also changing the header-line
face.  Introducing a new face that mode-line inherits from doesn't solve
this issue.

> 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.)

Making face remapping work reliably for these faces would be better, but
I haven't looked at the code.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





reply via email to

[Prev in Thread] Current Thread [Next in Thread]