[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#53636: 29.0.50; face-remapping broken on master
From: |
Eli Zaretskii |
Subject: |
bug#53636: 29.0.50; face-remapping broken on master |
Date: |
Thu, 03 Feb 2022 08:53:10 +0200 |
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 53636@debbugs.gnu.org, tsdh@gnu.org
> Date: Wed, 02 Feb 2022 20:48:42 +0100
>
> >> OK, you want to change the header-line and mode-line-inactive faces so
> >> that they no longer inherit from the mode-line face?
> >
> > Yes, I think this is the best way forward. Though it will be somewhat
> > backward-incompatible, if someone customizes mode-line and expects
> > header-line to follow suit.
>
> I think this would break a lot more than the current situation does.
Yes, it will. But if we want to break the link between mode-line and
header-line, I see no better way.
> Lots of people expect these faces to inherit the way they do, and have
> set up stuff based on that. Programmatic remapping of the `mode-line'
> face, on the other hand, is a much smaller issue, and we can just say
> "use `mode-line-active' instead".
That'd be fine with meas well,if it's acceptable.
> Note that in the other frame (displaying *Messages*), the
> mode-line-inactive face has inherited the underline from line-visited.
> (If I select that window, then the mode-line face has not, that is just
> in the current buffer.) So remapping a face that has inherited faces
> leads to side effects in other places...
When you remap a face, the faces that inherit from it are affected
only on new frames, because when we create a frame, we recompute the
set of the basic faces for it from scratch and thoroughly. That's
exactly the other side of the issue which started this discussion: the
inheriting faces on the original frame aren't affected by the
remapping of the parent face, but those same faces on new frames are.
> Anyway, what I was thinking of is a really simple solution: Have
> `face-remap-add-relative' loop over all children and remap them, too.
> (I haven't actually attempted to write something like that, though. 😀)
Why not leave this to the (small number of) applications that want to
do this?
- bug#53636: 29.0.50; face-remapping broken on master, Lars Ingebrigtsen, 2022/02/01
- bug#53636: 29.0.50; face-remapping broken on master, Eli Zaretskii, 2022/02/01
- bug#53636: 29.0.50; face-remapping broken on master, Lars Ingebrigtsen, 2022/02/02
- bug#53636: 29.0.50; face-remapping broken on master, Eli Zaretskii, 2022/02/02
- bug#53636: 29.0.50; face-remapping broken on master, Lars Ingebrigtsen, 2022/02/02
- bug#53636: [External] : bug#53636: 29.0.50; face-remapping broken on master, Drew Adams, 2022/02/02
- bug#53636: 29.0.50; face-remapping broken on master,
Eli Zaretskii <=
- bug#53636: 29.0.50; face-remapping broken on master, Lars Ingebrigtsen, 2022/02/03
- bug#53636: 29.0.50; face-remapping broken on master, Eli Zaretskii, 2022/02/03
- bug#53636: 29.0.50; face-remapping broken on master, Lars Ingebrigtsen, 2022/02/05
- bug#53636: 29.0.50; face-remapping broken on master, Eli Zaretskii, 2022/02/05
- bug#53636: [External] : bug#53636: 29.0.50; face-remapping broken on master, Drew Adams, 2022/02/05
- bug#53636: 29.0.50; face-remapping broken on master, Lars Ingebrigtsen, 2022/02/05
- bug#53636: 29.0.50; face-remapping broken on master, Eli Zaretskii, 2022/02/06
- bug#53636: 29.0.50; face-remapping broken on master, Lars Ingebrigtsen, 2022/02/06
- bug#53636: 29.0.50; face-remapping broken on master, Eli Zaretskii, 2022/02/07
- bug#53636: 29.0.50; face-remapping broken on master, Lars Ingebrigtsen, 2022/02/08