From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. Date: Sat, 07 Dec 2024 20:59:56 +0200 Message-ID: <86ttbfgvyr.fsf@gnu.org> References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86ldwrkeiy.fsf@gnu.org> <865xnviliv.fsf@gnu.org> <86wmgbgxjx.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23040"; mail-complaints-to="usenet@ciao.gmane.io" Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, monnier@iro.umontreal.ca, 73862@debbugs.gnu.org To: Aaron Jensen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 07 20:01:31 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tK03W-0005qJ-N1 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 07 Dec 2024 20:01:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tK03F-0006DV-NE; Sat, 07 Dec 2024 14:01:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tK036-0006D9-Cw for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2024 14:01:08 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tK034-0005KC-6y for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2024 14:01:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=BbcdIj3jWng+K3IxRN83koNbyM2z94mMXZm490pd/Mk=; b=bQbZRYtJ4+Xgj3lRJCp2TcRsHVO6Kgx3X/Dvs71qoph4qBsevzPutEGISASauyYLonl9N+UGEGEAD5GqnUq7VEgbQ7IEOyu9GeEPOBCwBvX6sNStx+UGwuduMwkmDELxYtWDrpji5WqKNW78X/YmTY9loh8jtit9kHhX9N3tCjCIcjNt29H0ZUyl2/MniaWrWG/OC/wceHRV2n6+7olD9wUaF2YSc0IlU6sv4P+agHEbQEC2mmY0EC58IvwPVWuyh7+nIJPMdS7BAkdeR9KrMpd/Pi41spb1esMc9uy7LPEnvkmiIVbxpsT6LnAuBpNCyjjslADOkz6ycCuvKPNBvA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tK034-0005S8-1x for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2024 14:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Dec 2024 19:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73862 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 73862-submit@debbugs.gnu.org id=B73862.173359801120799 (code B ref 73862); Sat, 07 Dec 2024 19:01:02 +0000 Original-Received: (at 73862) by debbugs.gnu.org; 7 Dec 2024 19:00:11 +0000 Original-Received: from localhost ([127.0.0.1]:48525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tK02E-0005PE-G0 for submit@debbugs.gnu.org; Sat, 07 Dec 2024 14:00:11 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50978) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tK02B-0005JG-AE for 73862@debbugs.gnu.org; Sat, 07 Dec 2024 14:00:08 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tK024-00053J-Vg; Sat, 07 Dec 2024 14:00:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=BbcdIj3jWng+K3IxRN83koNbyM2z94mMXZm490pd/Mk=; b=DN3wGzUCh7X/ CcIbGmI3ThKT68EV5YYsnN30vV5grZL+ivTW3CPRuW2szsCCqlsLyx8UVsUHhOe3shBXiEzSZc4sC VYkwG2vCGrrMyh0hoqrY2YejrELmDMera9GAK0+PBbqg3KHvw1e1UIs2MgwyujTAMdE76ZndQ8Y97 0nYEnKeQkfXAMq7JSPmNwp2oK0dvWDzJJRDDmOgiwUzAccJ/QZ7yFFT0SAFxYFK9x3SnV6RvqceoA 7fSgexYjCq0D0HCXTHVxUthaFDR2OFg0MJ5MdTyHgf9Cc2K1Z8wOReHlWlGnKbBH3zxG61dnN7M1C FqidyI7boQJ7roQcgTG1qg==; In-Reply-To: (message from Aaron Jensen on Sat, 7 Dec 2024 13:46:33 -0500) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:296593 Archived-At: > From: Aaron Jensen > 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 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.