From: Eli Zaretskii <eliz@gnu.org>
To: Aaron Jensen <aaronjensen@gmail.com>
Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com,
monnier@iro.umontreal.ca, 73862@debbugs.gnu.org
Subject: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces.
Date: Sat, 07 Dec 2024 20:59:56 +0200 [thread overview]
Message-ID: <86ttbfgvyr.fsf@gnu.org> (raw)
In-Reply-To: <CAHyO48xadqLDgjL-ajuksO7CHaVebcBD8=+q9R5qB9q6tfy0SA@mail.gmail.com> (message from Aaron Jensen on Sat, 7 Dec 2024 13:46:33 -0500)
> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 7 Dec 2024 13:46:33 -0500
> Cc: monnier@iro.umontreal.ca, trevor.m.murphy@gmail.com, me@eshelyaron.com,
> 73862@debbugs.gnu.org
>
> 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.
I'm sorry you interpret what I wrote as rude, or insulting, or
anything of that kind. If anything, it was supposed to be mildly
humorous. And when I say "you aren't supposed to", I don't mean you
personally.
So this is all a huge misunderstanding. My only motivation was to
explain what you see and maybe make Emacs a tad better, that's all.
Sorry.
P.S. My personal conclusion from this, and from many past bug reports
that causes us to add explicit remapping in many places, is that
face-remapping was a clever hack that should not have been allowed to
happen without a thorough rewrite of all the basic code which supports
faces and their merging. Hindsight is always 20/20.
next prev parent reply other threads:[~2024-12-07 18:59 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-18 12:56 bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces trevor.m.murphy
2024-10-27 10:46 ` Eli Zaretskii
2024-11-09 9:37 ` Eli Zaretskii
2024-11-11 6:11 ` Trevor Murphy
2024-11-16 14:11 ` Eli Zaretskii
2024-12-04 5:06 ` Aaron Jensen
2024-12-04 6:30 ` Aaron Jensen
2024-12-04 13:49 ` Eli Zaretskii
2024-12-05 3:06 ` Aaron Jensen
2024-12-05 6:22 ` Eli Zaretskii
2024-12-05 6:50 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-05 7:31 ` Eli Zaretskii
2024-12-05 6:53 ` Aaron Jensen
2024-12-05 7:29 ` Aaron Jensen
2024-12-05 7:51 ` Eli Zaretskii
2024-12-05 16:02 ` Aaron Jensen
2024-12-05 20:42 ` Eli Zaretskii
2024-12-05 21:14 ` Aaron Jensen
2024-12-06 8:55 ` Eli Zaretskii
2024-12-06 14:53 ` Aaron Jensen
2024-12-06 16:28 ` Aaron Jensen
2024-12-07 9:54 ` Eli Zaretskii
2024-12-07 9:50 ` Eli Zaretskii
2024-12-07 13:28 ` Aaron Jensen
2024-12-07 15:02 ` Eli Zaretskii
2024-12-07 17:13 ` Aaron Jensen
2024-12-07 18:25 ` Eli Zaretskii
2024-12-07 18:46 ` Aaron Jensen
2024-12-07 18:59 ` Eli Zaretskii [this message]
2024-12-07 19:06 ` Aaron Jensen
2024-12-07 19:19 ` Eli Zaretskii
2024-12-07 19:59 ` Aaron Jensen
2024-12-08 14:11 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-08 14:57 ` Eli Zaretskii
2024-12-08 16:29 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-08 17:26 ` Aaron Jensen
2024-12-08 17:39 ` Eli Zaretskii
2024-12-08 20:56 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-09 3:26 ` Eli Zaretskii
2024-12-09 8:56 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-14 9:45 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-22 15:52 ` Eli Zaretskii
[not found] ` <m1r05yk8e4.fsf@macbookpro.home>
2024-12-23 21:19 ` Aaron Jensen
2024-12-24 3:30 ` Eli Zaretskii
2024-12-24 5:17 ` Aaron Jensen
2024-12-24 12:44 ` Eli Zaretskii
2025-01-04 11:47 ` Eli Zaretskii
2025-01-04 20:23 ` Aaron Jensen
2025-01-05 7:42 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-05 10:41 ` Eli Zaretskii
2025-01-05 21:41 ` Aaron Jensen
2024-12-05 7:35 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86ttbfgvyr.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=73862@debbugs.gnu.org \
--cc=aaronjensen@gmail.com \
--cc=me@eshelyaron.com \
--cc=monnier@iro.umontreal.ca \
--cc=trevor.m.murphy@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).