On Sat, Dec 07, 2024 at 7:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> It shouldn't. If you apply it and see something like that, it should be
> considered a bug somewhere (but I would be very surprised if it did happen).
>

Ok, I tested it and you're right, I couldn't see this happen.

What I did see happen was if I did this:

(custom-set-faces '(header-line-active ((t (:inherit highlight)))))
(face-remap-set-base 'highlight 'default)

Then the remapping doesn't work. I'm not surprised at this point, but it's
still "surprising".  Given it's highly unlikely people would do something
like this, one could get away with a patch like this most likely.

All this change does it give the code the chance to account for remapping
> of header-line-active if header-line was remapped. But if the latter
> doesn't inherit from the former, that chance will not produce anything that
> depends on header-line's remapping.
>

Ok, thanks. I can't say I understand the code yet, I'd have to study it

Tab bar mode is another one that comes to mind that probably shouldn't use
> remaps at all when rendering.
>
> Why not?
>

Because it's rendered outside of a single buffer. I tried to use it for
https://github.com/aaronjensen/emacs-modern-tab-bar and it was a bad idea.
I added hooks to set the remaps in every buffer, but once I had a child
frame open or was away from the window, the remaps would not be in effect.
I ended up doing it with a custom theme, which worked fine and was a better
idea. So yes, technically, they "work" and if one anted to make the tab bar
look different while a single buffer was selected, they could, so I retract
my suggestion to make remapping not work there.

Thanks,