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: Fri, 6 Dec 2024 06:53:19 -0800 Message-ID: References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> <86jzcdkx6t.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000000726806289b2dbf" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15879"; mail-complaints-to="usenet@ciao.gmane.io" Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, Stefan Monnier , 73862@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 06 15:55:27 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 1tJZjr-0003xw-5I for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 06 Dec 2024 15:55:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tJZjV-0007Op-4v; Fri, 06 Dec 2024 09:55:05 -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 1tJZjS-0007J5-Oa for bug-gnu-emacs@gnu.org; Fri, 06 Dec 2024 09:55:02 -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 1tJZjS-0000nl-CJ for bug-gnu-emacs@gnu.org; Fri, 06 Dec 2024 09:55: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:In-Reply-To:From:References:Mime-Version:To:Subject; bh=AlZ4zEFoD17Mxpu2/xFvTJmnSErR2HI/8+KQhB6cPAc=; b=WFZB8AIiYQeeBRY1YkeTQWUck57zEURMuErDingz1IJAMCN7PQLFpM+knsxDEgmi7T2qe+QXQ343I9eq5ZDiJfbj30KvOtAM7GCHqEooqtQURQ1q1valIaBEaZdA9PPNXLRvqbHseI0SSuxExi7TC6jg77K7ZFtmmyv7Y/4nsytog3Z2s4rWHrk4/wVxb8c1sg9eUxM03B+/2iva/tVN9vr/0B9Qfpv9mtDu/QAHJRwnhdTmtK8FrBLy94Jvhcgg6tF+gOeQFdRDaTr2KJ4AD2HBiA3v4cpXbEO9vGU+IxafCNMYELmizPhD5s4RW053PrYo2NE3BnnJQzVI7qH87w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tJZjR-00056y-St for bug-gnu-emacs@gnu.org; Fri, 06 Dec 2024 09:55: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: Fri, 06 Dec 2024 14:55: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.173349687019588 (code B ref 73862); Fri, 06 Dec 2024 14:55:01 +0000 Original-Received: (at 73862) by debbugs.gnu.org; 6 Dec 2024 14:54:30 +0000 Original-Received: from localhost ([127.0.0.1]:42483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJZiw-00055s-4a for submit@debbugs.gnu.org; Fri, 06 Dec 2024 09:54:30 -0500 Original-Received: from mail-lj1-f178.google.com ([209.85.208.178]:42407) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJZis-00055Z-Ju for 73862@debbugs.gnu.org; Fri, 06 Dec 2024 09:54:27 -0500 Original-Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-30024c73101so17633991fa.1 for <73862@debbugs.gnu.org>; Fri, 06 Dec 2024 06:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733496801; x=1734101601; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:in-reply-to:from:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AlZ4zEFoD17Mxpu2/xFvTJmnSErR2HI/8+KQhB6cPAc=; b=dDhTFk33BJaMKNebxw2k2L23HUEA3oepdVXwskwc9RDTZ0PdgGofOYRV9CT/GxrjHg vkj7uSOZLOZeCoHf6M70aGdAuzyIiL8B8ChwvqlXxDsYfoFaT9NNvClmZlwmO9FiO2gN x2oA20o1hZGJIxr9KP81a+soaIswoAuCgqVH6BdsawIYQTHa2zOjccJzSdsaAUYr2vrp 55Qk/jvmaBonbT4U9lr6ogp9v9lYZUWydBm13g/LhquSOpESj1MZIEOIh/Lfd57iHGAW zmqT9VQk4Fboff5UgEZKSloFD1WyvL1ch9rbBpbC0disbQMjbuT+Um/BCTKkqBDz1F8c neDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733496801; x=1734101601; h=cc:to:subject:message-id:date:in-reply-to:from:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AlZ4zEFoD17Mxpu2/xFvTJmnSErR2HI/8+KQhB6cPAc=; b=p6AsrBdzFNilXr4gWKuby2S/OMH3P5rzPfHslpp0fMHP0rdjLHitNguz+v0kPv+fJN Ruz1cCfj0r5CTc8TEXuiJo8LaOzsP+P8FxX7fq1w/pl10mcr7aMf2PS3OMNAjyp8Pt2r cQcBBn7tgScen6cL/173K8hwAuEMOIQiTmjmPlfCHVT0h/IwYrbPmEzqjwgSD6HEX98o EhrbW4rMxzhrYgeAZCnoVVbxsqhkQElKvRvmDRnKJsJJ3aP9ZWOLckOAjr0B41bxIKYx WXTCuU88CqScV5sHb3saOXCmuQ9jEVPuanQHtsnpxhS+bjZDOOK0+lmuSYWejFIUv1go oROg== X-Forwarded-Encrypted: i=1; AJvYcCVRU2TOK9Qj8XPVkXuG14lO1hDgvq5TlVQGw53rZO9YOY3ghJrZXEZz/m6vAAzLWLNkLZtB7A==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwnHZwUCiO5jzriVChNnsYiqwU9/RRfdPH8LI7qvml2cxR4yMlE gWSz4MamEDPrkFOqIKDe+hfop+xhNqSaFtvBy7HTpkKHkya/Bv3i6hpW3qbkp4Mnob6BHDkAfv5 fEUqmNCKy9rZa37iKBzQjbl/iSNg= X-Gm-Gg: ASbGnct1TLZFgrThzK0i8KAHnbLLgsKZaRTu5J+nlkvdOFn7jC8xDvmzm4O2wp49POq 28by2u67lD/FWlC5YjWJEl1M/fn39Hk0LLiNExj3snNqCF/puH0ifcqI= X-Google-Smtp-Source: AGHT+IF6Q31/WaVsjYudnF53/d+JApFgJGZnHoiad5NTPtu206kar3ULC8adrpOuXm1okuaGiedXt3/HRdlW3jCcUpQ= X-Received: by 2002:a2e:be23:0:b0:2ff:b3f0:68d9 with SMTP id 38308e7fff4ca-3001ea9934bmr29057331fa.3.1733496800307; Fri, 06 Dec 2024 06:53:20 -0800 (PST) Original-Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Fri, 6 Dec 2024 06:53:19 -0800 X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-ID: m4cv833p.58fe6f03-dccd-421b-b42d-cfc57b54c332 X-Superhuman-Draft-ID: draft009be574a1d2170b In-Reply-To: <86jzcdkx6t.fsf@gnu.org> 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:296502 Archived-At: --00000000000000726806289b2dbf Content-Type: text/plain; charset="UTF-8" On Fri, Dec 06, 2024 at 12:55 AM, Eli Zaretskii wrote: > See above: I hope the situation is more clear now. > Yes, thank you. I still don't know all of the different things that trigger computation of faces, but I probably don't need to (and likely shouldn't need to). So I tend to close this bug as wontfix, and just mention in the > documentation (NEWS at least) that people who remap header-line or > mode-line need now to remap the new -active and -inactive faces. > > Ok, I get what you're saying here, but I don't know that I agree with > this: > "...people somehow expect that remapping the header-line face will affect > header-line-active and header-line-inactive." I'm not sure why it wouldn't > be expected. > > It shouldn't be expected for basic faces. > >From a purely human, cognitive load, and/or usability perspective, it should be expected. As designers of software we have to be careful not to let our detailed knowledge of things influence how we think other people who do not have that detailed knowledge will or should think about things. I was speaking purely from a "principle of least surprise" perspective. All I mean is that if there are 10 widgets, and 9 widgets work a certain way when you push a button on them, it is human and natural to expect the 10th to work that same way. It doesn't matter that the builder of the widget refers to it as a "basic widget", because the user of the widget has never come across that terminology, nor do they know what special variation it confers. It does sound like below you agree that the situation caused is undesirable, I'm trying to speak to why I believe it is. But yes, perhaps the train has left the station though. Or we could do what the mode-line case did originally: leave the active > face to be header-line and define header-line-inactive without inheritance. > This will at least let existing remapping of header-line work as it did > before. > > For the same reasons, I would prefer to go back on the mode-line-active > change, but I'm not sure this is practical at this point. > I'd personally be fine with this. It would be obvious when an inactive header line looked different than my header line I configured and I would have to look into it. I'm guessing there's no way to apply header-line-active and header-line-inactive to the actual formatted header line in the same way a user would with propertize so that it would behave like a non-basic face? I have no idea what that would entail, but I'm assuming there's a special reason for treating basic faces specially (perhaps it has to do with how init_iterator is initialized with it) This would mean that the base faces, header-line and mode-line would be > eliminated. > > No need to go that far. These faces are still useful, because they allow > to define the inheriting faces more compactly, and allow to change the > definitions easier. Inheritance still works on the defface level, even for > basic faces. > I think you're saying above you'd prefer nearly the same thing, but header-line would survive, rather than header-line-active, yes? The point is that inheritance only "kind of" works for basic faces (from a user's perspective), so no matter how we get rid of the default use of inheritance, I think it would be better for users. Thanks, --00000000000000726806289b2dbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 06, 2024 at 12:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
<= div class=3D"sh-quoted-content">
=

See above: I hope the situation is more clear now.


Yes, thank you. I = still don't know all of the different things that trigger computation= =C2=A0of faces, but I probably don't need to (and likely shouldn't = need to).

So I tend to close this bug as wontfix, and just mention in the documentation (NEWS at least) that people who remap header-line or mode-line need now to remap the new -active and -inactive faces.

Ok, I get what you're saying here, but I don't know that I agree wi= th this:
"...people somehow expect that remapping the header-line face will aff= ect header-line-active and header-line-inactive." I'm not sure why it = wouldn't be expected.

It shouldn't be expected for basic faces.


From a purely human, co= gnitive load, and/or usability perspective, it should be expected. As desig= ners of software we have to be careful not to let our detailed knowledge of= things influence how we think other people who do not have that detailed k= nowledge will or should think about things. I was speaking purely=C2=A0from= a "principle of least surprise" perspective. All I mean is that = if there are 10 widgets, and 9 widgets work a certain way when you push a b= utton on them, it is human and natural to expect the 10th to work that same= way. It doesn't matter that the builder of the widget refers to it as = a "basic widget", because the user of the widget has never come a= cross that terminology, nor do they know what special variation it confers.=

It does sound like below you agree=C2=A0that = the situation caused is undesirable, I'm trying to speak to why I belie= ve=C2=A0it is. But yes, perhaps=C2=A0the train has left the station though.=

Or we could do what the mode-line case did originally: leave the active face to be header-line and define header-line-inactive without inheritance. This will at least let existing remapping of header-line work as it did before.

For the same reasons, I would prefer to go back on the mode-line-active change, but I'm not sure this is practical at this point.

I'd personally be fine with this. It would be obvious when= an inactive header line looked different than my header line I configured = and I would have to look into it. I'm guessing there's no way to ap= ply header-line-active and header-line-inactive to the actual=C2=A0formatte= d header line in the same way a user would with propertize=C2=A0so that it = would behave like a non-basic face? I have no idea what that would=C2=A0ent= ail, but I'm assuming=C2=A0there's a special reason for treating ba= sic faces specially (perhaps it has to do with how init_iterator is initial= ized with=C2=A0it)

This would mean that the base faces, header-line and mode-line would be eliminated.

No need to go that far. These faces are still useful, because they allow to define the inheriting faces more compactly, and allow to change the definitions easier. Inheritance still works on the defface level, even for basic faces.


I think you're saying above you'= d prefer nearly the same thing, but header-line would survive, rather than = header-line-active, yes? The point is that inheritance only "kind of&q= uot; works for basic faces (from a user's perspective), so no matter ho= w we get rid of the default use of inheritance, I think it would be better = for users.

Thanks,

--00000000000000726806289b2dbf--