On Fri, Dec 06, 2024 at 12:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:

See above: I hope the situation is more clear now.

Yes, thank you. I still don't know all of the different things that trigger computation of faces, but I probably don't need to (and likely shouldn't need to).

So I tend to close this bug as wontfix, and just mention in the documentation (NEWS at least) that people who remap header-line or mode-line need now to remap the new -active and -inactive faces.
Ok, I get what you're saying here, but I don't know that I agree with this:
"...people somehow expect that remapping the header-line face will affect header-line-active and header-line-inactive." I'm not sure why it wouldn't be expected.
It shouldn't be expected for basic faces.

From a purely human, cognitive load, and/or usability perspective, it should be expected. As designers of software we have to be careful not to let our detailed knowledge of things influence how we think other people who do not have that detailed knowledge will or should think about things. I was speaking purely from a "principle of least surprise" perspective. All I mean is that if there are 10 widgets, and 9 widgets work a certain way when you push a button on them, it is human and natural to expect the 10th to work that same way. It doesn't matter that the builder of the widget refers to it as a "basic widget", because the user of the widget has never come across that terminology, nor do they know what special variation it confers.

It does sound like below you agree that the situation caused is undesirable, I'm trying to speak to why I believe it is. But yes, perhaps the train has left the station though.

Or we could do what the mode-line case did originally: leave the active face to be header-line and define header-line-inactive without inheritance. This will at least let existing remapping of header-line work as it did before.
For the same reasons, I would prefer to go back on the mode-line-active change, but I'm not sure this is practical at this point.

I'd personally be fine with this. It would be obvious when an inactive header line looked different than my header line I configured and I would have to look into it. I'm guessing there's no way to apply header-line-active and header-line-inactive to the actual formatted header line in the same way a user would with propertize so that it would behave like a non-basic face? I have no idea what that would entail, but I'm assuming there's a special reason for treating basic faces specially (perhaps it has to do with how init_iterator is initialized with it)

This would mean that the base faces, header-line and mode-line would be eliminated.
No need to go that far. These faces are still useful, because they allow to define the inheriting faces more compactly, and allow to change the definitions easier. Inheritance still works on the defface level, even for basic faces.

I think you're saying above you'd prefer nearly the same thing, but header-line would survive, rather than header-line-active, yes? The point is that inheritance only "kind of" works for basic faces (from a user's perspective), so no matter how we get rid of the default use of inheritance, I think it would be better for users.

Thanks,