From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aaron Jensen Newsgroups: gmane.emacs.bugs Subject: bug#73862: [PATCH] Add `header-line-active` and `header-line-inactive` faces. Date: Sat, 7 Dec 2024 13:46:33 -0500 Message-ID: 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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f738a70628b28cc1" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15186"; 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: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 07 19:48:23 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 1tJzqo-0003mY-Pk for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 07 Dec 2024 19:48:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tJzqY-00052J-0j; Sat, 07 Dec 2024 13:48:06 -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 1tJzqV-00051x-AG for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2024 13:48:03 -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 1tJzqU-00048l-BO for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2024 13:48:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:References:In-Reply-To:Mime-Version:To:Subject; bh=aHn6vwITilklVmuJT3zydfgg8jCxZWbpqZ/2EqZSYZc=; b=Xc0k+cY5GgS0G9pvaLlDrh5/kIhxTjT2+5R1XVY+VEDHQqkzt50F7aBb4Q6XoKqM/CisoCXVUX7I8h3bptevVaqxSlzhsRphYpz0s798V6Ckwk+i3ywjMXRg+SkLYF/whR+UwHrFxabF/0kA+2WrhiRJdlrYM67JZlKZKG8y892zb6wgsDmOXWLq9NOuORsuxB420MqcjaWIjlYsXK36lUdfq4AprdxaZ/KhhddG3Rf/uxlgNvxSuJDKP4ysOcCzkpDFUdotMruP8/znxa6dZ+LFIVw/NG9IgqPMIS+AxKnIs2WlvUbCRGa5urd6B5jPvu7J54bOId0/eIsr2oUh3Q==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tJzqT-0004kw-ST for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2024 13:48:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Jensen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Dec 2024 18:48:01 +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.173359725918244 (code B ref 73862); Sat, 07 Dec 2024 18:48:01 +0000 Original-Received: (at 73862) by debbugs.gnu.org; 7 Dec 2024 18:47:39 +0000 Original-Received: from localhost ([127.0.0.1]:48504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJzq7-0004kC-2J for submit@debbugs.gnu.org; Sat, 07 Dec 2024 13:47:39 -0500 Original-Received: from mail-lj1-f178.google.com ([209.85.208.178]:57428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJzq3-0004k2-S4 for 73862@debbugs.gnu.org; Sat, 07 Dec 2024 13:47:37 -0500 Original-Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2ffbf4580cbso32255681fa.2 for <73862@debbugs.gnu.org>; Sat, 07 Dec 2024 10:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733597195; x=1734201995; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aHn6vwITilklVmuJT3zydfgg8jCxZWbpqZ/2EqZSYZc=; b=OurZ1EY3yhvyCSeWgbptL2cK3qTkH/C3ViBc/daCBNv8PFCont09Wy3vwCA5XKA36u VwKO1sqwySsyUH3HRK94sySjINxkZkj1wGHtRfAKRBqXALcGqol3b5xpQsGotF37Pv4f ppOUtiQipYOUJWJG/e85UbrqwU9NECnOzyli/K9t0Cy2h+cCOuhhaGASJpYFJKqliqIQ Db4voJSgANYtcGNqtgToJDwTQs0AG/xELvbTe19SFFssZ2IrFbfo7bZNsDMfhZYNG+/G NRDqq/pCSHKHGamUI1McwZsYwzC6ewNGI/umhgg5zaWPCvHBjke1mzG044lN8YWws+CL TrqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733597195; x=1734201995; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aHn6vwITilklVmuJT3zydfgg8jCxZWbpqZ/2EqZSYZc=; b=bbxF3ZI6qtC8phuVvPzUQL5OV+1GjjgJGu0MbbaLOzVfiHHFLyvPW4iUSZQxpM3Yx+ LNxuZyXZAyUmM7cOgPHrrzSlhO8n6IEQpvxLysw25qH+q37LVKosvUafucK2jzToSZNK WX9mbmMq3vCIzYC8oKqCFlvOtjiTnw8tQiFPrV1gh0XWT5gpns4dSAxx9jc2XRzraEDF OJvjU1pP8h9iv21y0RIJgZBhKUg8hDCC5Cddps14dIgefGOSKUJm56E02Wpb0zNlmoC0 80DWvFC7sgLFcKbxGWmdjSJugp9JRpRRsXhq3Oqo8A25XJdLEJVxPoAX5A/coosxI98n WKTg== X-Forwarded-Encrypted: i=1; AJvYcCXXAriEZosrV98n/JijluoXjF8QQ7JtUZHF0+wIX/paO0XJ0CjMuEE4eFCuMcxMkdrtcYuYzA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yyk1/QFeHiQQ5RbvnvtPP+0HWXqhU/g3d8lc9mjiubu8LDMmOY8 M2Jvuhno9toox/CiYJh42gMtDbvGe5GId1qdiTbjvbMdJDHs8WrA8EYSLh1hmzzEXJJi1Q1mcon WisHuBfLg8wzh2R0wMraCyJPEamE= X-Gm-Gg: ASbGncvD675OkEd6hL8nAUqsmOfioB9ND2uXLZ8qSheVkHiAtXjt/lRcNmSfOhBhRAo uPhDu4wc2IC1vgQFff3KlIudb4//T221jVFIp4ia7nm09noPfqX6rBwHY X-Google-Smtp-Source: AGHT+IHJBujf5uB1ZRB7Af2nP+EJtTi7c/OcRSSZa17pu42y4E+r+2WKmoQSb+Rha5MES660ZhkI9XkIdKqedKzZnGk= X-Received: by 2002:a2e:9a0e:0:b0:300:1f12:3d54 with SMTP id 38308e7fff4ca-3002f62f680mr35589601fa.1.1733597194562; Sat, 07 Dec 2024 10:46:34 -0800 (PST) Original-Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Sat, 7 Dec 2024 13:46:33 -0500 In-Reply-To: <86wmgbgxjx.fsf@gnu.org> X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-ID: m4eizvg6.38fd5ae4-1367-402f-b014-79191ae116f0 X-Superhuman-Draft-ID: draft0095f23857e0a4bd 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:296592 Archived-At: --000000000000f738a70628b28cc1 Content-Type: text/plain; charset="UTF-8" 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. Aaron --000000000000f738a70628b28cc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 07, 2024 at 10:25 AM, Eli Zaretski= i <eliz@gnu.org> wrote:<= br>

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 cir= cumstances. I'm not being obstinate here. I'm not expecting Emacs t= o do something it never did. I'm only representing the beginner's m= ind. The thing that we *should* be considering when designing tools. Develo= pers "knowing better" than users is what makes so much of the sof= tware we use garbage. Emacs isn't garbage, but I'm trying to commun= icate that this behavior is surprising because there is no explicit (that I= know of) differentiation between "basic" faces and non-"bas= ic" faces.=C2=A0

Yo= u said this about me not knowing about basic faces: "As a Lisp programmer, you aren't supposed to know that, or c= are."

And I'm saying that as someone w= ho does not know what a basic face is, how in the world can I be expected t= o know or intuit that this classification I do not know exist means that in= heriting and remapping doesn't work? That is my *only* point.=C2=A0
<= div class=3D"">

They are called "basic" because they aren't supposed to inher= it 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 rea= lly what they are, and that were codified and explicit, the guard rails wou= ld be in place to teach the beginner users. I would prefer this to somethin= g that enables backwards compatibility, but that ship may have sunk (sailed= ) already. A combination of the two things could work as well (explicit=C2= =A0backwards compatibility, for mode-line and header-line faces, but a warn= ing 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&qu= ot;.

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=C2=A0for it and has to learn through trial and error. It= 's part of what makes Emacs Emacs. I learned something about face remap= ping and themes in building that package and I'm glad to know it.

That said, as software designers, we are not suppos= ed to be frustrated be insulting when our users complain "that things = fall apart", nor should we think of it as trust not being justified. W= e can miss the target too. If our designs are not intention revealing, or a= re "surprising", we should recognize that as feedback and recogni= ze=C2=A0we 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 an= ywhere good, in my experience. There will always be users that we could nev= er "dumb things down" enough for, and if that's how=C2=A0I= 9;m coming across right now, I apologize.

Aaro= n

--000000000000f738a70628b28cc1--