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,