GNU bug report logs - #73862
[PATCH] Add `header-line-active` and `header-line-inactive` faces.

Previous Next

Full log

View this message in rfc822 format

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: trevor.m.murphy <at> gmail.com, me <at> eshelyaron.com, Stefan Monnier <monnier <at> iro.umontreal.ca>, 73862 <at> debbugs.gnu.org
Subject: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces.
Date: Fri, 6 Dec 2024 06:53:19 -0800

[Message part 1 (text/plain, inline)]

On Fri, Dec 06, 2024 at 12:55 AM, Eli Zaretskii <eliz <at> 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,

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.