GNU bug report logs -
#73862
[PATCH] Add `header-line-active` and `header-line-inactive` faces.
Previous Next
Reported by: trevor.m.murphy <at> gmail.com
Date: Fri, 18 Oct 2024 12:58:02 UTC
Severity: wishlist
Tags: patch
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #39 received at 73862 <at> debbugs.gnu.org (full text, mbox):
Hi Eli,
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Aaron Jensen <aaronjensen <at> gmail.com>
>> Date: Wed, 4 Dec 2024 19:06:26 -0800
>> Cc: Trevor Murphy <trevor.m.murphy <at> gmail.com>, Eshel Yaron <me <at> eshelyaron.com>, 73862 <at> debbugs.gnu.org
>>
>> You were able to reproduce what? I don't think you posted a recipe to reproduce the problem. Please
>> do, if at all possible, preferably starting from "emacs -Q".
>>
>> I didn't — I thought I mentioned that. I had intended to provide one as soon as I had a chance to, but it turns
>> out that Eshel encountered the same issue and provided a recipe (thank you, Eshel). The only difference in
>> my case is that face-remap-set-base is used, rather than face-remap-add-relative.
>>
>> As far as I can tell, this same bug occurs in the mode-line as well as the header-line. I.e., there was an
>> existing bug in the mode-line and it was replicated to the header-line after the two new faces were added.
>
> If what you see is the same as Eshel, I will ask you the same
> question: shouldn't you apply face-remapping to the 2 new faces
> instead of the 'header-line' face from which they both inherit?
> What happens if you do define remapping for those two new faces?
At least to me, it's not clear what you mean by "should". Existing code
remaps the header-line face with good results (prior to this change), so
if we now "should" remap something else instead to get the same results,
that means this is a breaking change. Is that intended? If so, OK, if
not, shouldn't it be fixed? :)
Thanks,
Eshel
This bug report was last modified 214 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.