unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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).