[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: |
Wed, 02 Feb 2022 20:48:42 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> 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.
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".
>> No, I don't. I was thinking of altering `face-remap-add-relative' so
>> that it resolves the faces that inherit instead of leaving it to
>> redisplay.
>
> I don't think this can work, because that would mean the original face
> will be affected by remapping, won't it? Face remapping is
> buffer-local, whereas faces are defined for the entire frame. So we
> cannot affect the original face and keep the effect buffer-local. And
> if we produce a different face symbol and modify it instead, then
> references to the original face symbol will not be redirected to the
> remapped face.
Hm... That's not quite what I'm seeing with the mode line faces.
In Emacs 28, with
emacs -Q
(face-remap-add-relative 'mode-line 'link-visited)
C-x 5 2
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...
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. 😀)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
- 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 <=
- 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, 2022/02/03
- 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