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

[Aaron Jensen <aaronjensen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]

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

> Repeat after me: "basic faces cannot follow remapping due to face
> inheritance".
>

Oh, I know that *now*. I also know what basic faces are *now*. I'm no
longer ignorant to this, and, for what it's worth, this came across as rude
given the circumstances. I'm not being obstinate here. I'm not expecting
Emacs to do something it never did. I'm only representing the beginner's
mind. The thing that we *should* be considering when designing tools.
Developers "knowing better" than users is what makes so much of the
software we use garbage. Emacs isn't garbage, but I'm trying to communicate
that this behavior is surprising because there is no explicit (that I know
of) differentiation between "basic" faces and non-"basic" faces.

You said this about me not knowing about basic faces: "As a Lisp
programmer, you aren't supposed to know that, or care."

And I'm saying that as someone who does not know what a basic face is, how
in the world can I be expected to know or intuit that this classification I
do not know exist means that inheriting and remapping doesn't work? That is
my *only* point.

They are called "basic" because they aren't supposed to inherit from
> anything, but be used to inherit _from_.
>

If this were *prevented* or a warning in some way, this would solve all of
the problems. If this is really what they are, and that were codified and
explicit, the guard rails would be in place to teach the beginner users. I
would prefer this to something that enables backwards compatibility, but
that ship may have sunk (sailed) already. A combination of the two things
could work as well (explicit backwards compatibility, for mode-line and
header-line faces, but a warning when "basic" faces inherit from anything
else).

The patch I posted is supposed to make Emacs be more backward-compatible,
> in that people who used to remap header-line will see their remapping
> propagate to header-line-active etc., but only as long as they inherit from
> header-line, which they do by default. Making header-line inherit from
> highlight didn't work before, and should not be expected to work now.
>
> If we install the patch I posted, I wouldn't even document this special
> handling of these faces, because its only purpose is to help with backward
> compatibility.
>
> I'm not surprised at this point, but it's still "surprising".
>
> It had never worked! And was not supposed to work!
>

I believe you are misunderstanding my use of the word "surprising". I hope
it's more clear now.

As with many Emacs features, users shoot themselves in the foot by
> (ab)using the features outside of their intended design space, and then
> complain that things fall apart. Emacs trusts the users that they know what
> they are doing, although that trust is not always justified, it seems...
>
>
Aye, even someone who has been using Emacs for nearly 10 years does not
know everything about customizing it and building packages for it and has
to learn through trial and error. It's part of what makes Emacs Emacs. I
learned something about face remapping and themes in building that package
and I'm glad to know it.

That said, as software designers, we are not supposed to be frustrated be
insulting when our users complain "that things fall apart", nor should we
think of it as trust not being justified. We can miss the target too. If
our designs are not intention revealing, or are "surprising", we should
recognize that as feedback and recognize we may have gotten something
wrong. Our users are doing us a favor by giving us feedback in that moment.
Belittling them doesn't get us anywhere good, in my experience. There will
always be users that we could never "dumb things down" enough for, and if
that's how I'm coming across right now, I apologize.

Aaron

[-- Attachment #2: Type: text/html, Size: 6457 bytes --]