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: Thu, 5 Dec 2024 13:14:32 -0800 Message-ID: References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000075d11a06288c62cb" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16020"; mail-complaints-to="usenet@ciao.gmane.io" Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 05 22:16:29 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 1tJJD3-00042X-28 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Dec 2024 22:16:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tJJCm-0004UG-QN; Thu, 05 Dec 2024 16:16:12 -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 1tJJCc-0004TV-H5 for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2024 16:16: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 1tJJCc-0002Ov-61 for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2024 16:16: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=5PIMDJPHOLUmQ0zWMxLghhMUoxO4V26RRbjDe94+vLc=; b=Uzle4G5PQJRPYZaD+GMQDhrbQ6In4P1mw06vzPPzUKX485GgWItqomfQczNSXSkU7j/IMt67cBbMSe1lsZhs6NG3CG83wqp1wgolXUd5uyY/Mer06AzdsAu/TIOxWyMv7ZQ6E75u0k01c5tXG5Zm9nHD3FY+dGbFfZ0zwsQAS164jnOOWfTda2hHp34I+q04du7xiZ7jCWiOXwWRYWWcSKmV/Lgsd+0ymEJT7oTh/gvjdt1wt5S/l+3GzEyyJFp0rsAlusVk8/JS9mgCGExTvFU1x7vRZur9xrZqw5sejUl3creXh7ZXfRhjxLX/KfO1HmO/kYP4VN6U1pP1fhRxbA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tJJCb-0003tm-WB for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2024 16:16:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Jensen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Dec 2024 21:16: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.173343334314952 (code B ref 73862); Thu, 05 Dec 2024 21:16:01 +0000 Original-Received: (at 73862) by debbugs.gnu.org; 5 Dec 2024 21:15:43 +0000 Original-Received: from localhost ([127.0.0.1]:41191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJJCI-0003t5-C2 for submit@debbugs.gnu.org; Thu, 05 Dec 2024 16:15:43 -0500 Original-Received: from mail-lf1-f44.google.com ([209.85.167.44]:45343) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJJCE-0003sl-S8 for 73862@debbugs.gnu.org; Thu, 05 Dec 2024 16:15:40 -0500 Original-Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-53e1f673ca8so1559747e87.3 for <73862@debbugs.gnu.org>; Thu, 05 Dec 2024 13:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733433273; x=1734038073; 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=5PIMDJPHOLUmQ0zWMxLghhMUoxO4V26RRbjDe94+vLc=; b=O5yBvjn0noitLz1Gc6cDEH37+a61snx/zwYWswR16BSkxKjyBX3dM09pIx2lcbUvM4 ulIE00LU01dcsMsRZG8jO6dQKtZnHNkl3tQxEaLxbUNQmKhV/D79pOde832YDxHZze2K 5Q2ktBuAfN2NY02P2/nWmfV5wcYMUO15u0gKg0P28GO16rXbFZWcES9djewi/MlF2QtY 7UVUYlMqvcrk3UH1ZigjTZK/bFZcjHH2pmMucb7lELuRLB25s1E49gQoW7qQJayIiNqt 3H/sTQrsG28jxNI7XzWo1ipfr6ZlhxTtVOmbz6QMazE6cL9q2CKa1Fa0aS6sgrScrq41 HtWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733433273; x=1734038073; 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=5PIMDJPHOLUmQ0zWMxLghhMUoxO4V26RRbjDe94+vLc=; b=dvUkff7DIc9KHI1NlIXlkTzgY8d3wZ4hGp6tWZG9iIhThbgXlexUUen/RWZ2R+/xPU 9oUO2c7ptzuvEuJwto0UfiuBVuxrchv8XE0WBseu04zDipCFotr6Erwa2FXc9JAPUp4n f7jfP6om2Z8ZgN8fay5QwVaJCZ21mNyy1gJzw8XD969oXrHc6WgZfzYCVlY0eN6ShLJI ZL3+wZve1eOxnxuX3nFguB4IYOXhNuf7U4wDDtKyGBH1tnShjgb43725jOf6ZCHp4P9e LmtSVi2fK98hfTfbyG6K4ENsRBK4m7NQZSTMSekMBIdTa/aOlRPv15wpaqdenZYEQMtK GrbA== X-Forwarded-Encrypted: i=1; AJvYcCXdNBObBzOhKL7jSFTjyRo5f9MduOG+CCWFhy7OWctaPaqqjrdxzUOsJj5p9aKww59i43vpsA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywtl9ZLNnwwTHLUnghZ63PstYwdeCoxty25aDxezUzpFBSSRx+G uOLGN1mBvUvn8TlNxogGO+Wctrxon1oOWzk1GWdweal5pTYbRBBZyv0/Oc8O6pCtHQu4U56JKRe IkPhPBdnL9H3SPLz9m4d8cXzruZM= X-Gm-Gg: ASbGncsFW9wzebx9xN17s7PMGwVSxAey3TLNk4RupiGTugZ4IB9piZr4yrBgOlU3Ivf AjmkHrOdAc1/rVIPEMmvhytSzhuaEq+pyGfmC/QIxPByA8xiDv8lB0j4= X-Google-Smtp-Source: AGHT+IGCO5x0Fi6Zxh4bTYk9xIL2sVpcsMBDMbh6xX3QJ46r3QeL7euVxezqWlRDWc3Cn5BqzxkxtplXZnLlszftLyY= X-Received: by 2002:a05:6512:2316:b0:53d:dd02:7cc5 with SMTP id 2adb3069b0e04-53e2c2b12b9mr117204e87.7.1733433272681; Thu, 05 Dec 2024 13:14:32 -0800 (PST) Original-Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Thu, 5 Dec 2024 13:14:32 -0800 X-Mailer: Superhuman Desktop (2024-12-02T20:06:08Z) X-Superhuman-Draft-ID: draft006cbc1e2fd7c16a In-Reply-To: <8634j1n9nx.fsf@gnu.org> X-Superhuman-ID: m4bteggn.f03491e8-24c7-47c8-b0e6-70086f97449c 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:296484 Archived-At: --00000000000075d11a06288c62cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 05, 2024 at 12:42 PM, Eli Zaretskii wrote: > From: Aaron Jensen > Date: Thu, 5 Dec 2024 08:02:06 -0800 > Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org > > On Wed, Dec 04, 2024 at 11:51 PM, Eli Zaretskii wrote: > > Once again, please show some simple Lisp to reproduce the phenomena you > are observing. It is hard to discuss these highly technical issues on thi= s > abstract level. > > Happy to. Sorry, I didn't think it was necessary given Eshel's providing > of the recipe. > > I asked a recipe from you because you seemed to be reporting something > different: the happening once" part. > > 1. (setq header-line-format "Some Header") > 2. (face-remap-set-base 'header-line 'highlight) > 3. (set-face-attribute 'default nil :height (+ (face-attribute 'default > :height) 10)) > 4. (switch-to-buffer-other-window "new") > 5. From within new buffer/window: (set-face-attribute 'default nil > :height (+ (face-attribute 'default :height) 10)) > > You'll see after step 3 the header line switches to the highlight face. > After step 5, the header line in the original buffer switches away from t= he > highlight face, which is unexpected. > > Why are you changing the attributes of the default face in step 3 and ste= p > 5 when what you want is to change the header-line face? And do you > understand why step 2 didn't change the way header line is displayed, but > step 3 did? > Only to force a redisplay in a way that actually causes the inheritance to be considered. Note that when you reproduce this same thing with the mode-line, force-mode-line-update doesn't work to cause the inheritance to be considered. There's something "special" about changing the font or the geometry of the frame or something that's causing the consideration of inheritance. > If you then switch back to the original buffer and change the font size > again, the highlight will display again. > > How come the font of the default face affects the colors of the > header-line faces? Doesn't that already look strange? > The strange thing is that when and how the inheritance is taken into account is not the same as for other faces. So yes, it already looks strange =E2=80=94 I shouldn't need to force a redisplay. Affecting the font= of the default face is just one means by which I can trigger the redisplay in a way that causes the issue. The specifics of it are a red herring. When I first noticed the issue it was as a result of a vterm popup window being shown. No default font modifications were made. I don't know what the specific trigger was, however. > Switching back to the new buffer and changing the font size causes it to > disappear again, so I was mistaken about it only happening once. > > OK, so that mystery doesn't exist. Good. > > On the very basic level of the display code, when a display iterator is > initialized, the window for whose display the iterator is used must be > given to init_iterator as its argument, and the buffer of that window mus= t > be temporarily made to be the current buffer. So this cannot be the probl= em > in this case. If init_iterator would be passed an incorrect window, we'd > have much more grave display problems than this minor issue. > > Understood, but that's not what I was attempting to describe. I was tryin= g > to say that the window passed to init_interator IS the correct window. An= d > that that is used to resolve the remap for the inactive/active faces. > However, it does not appear that that same window is used to resolve > remapping of faces that are inherited by the inactive/active faces. > > Face remapping is local to buffers, not to windows. So which window is > passed to init_interator is not relevant to face remapping; the buffer of > that window is. > My mistake. Even so, the buffer isn't being taken into account consistently, but you speak to that below. > From what I can tell, this only applies to header-line-active and > header-line-inactive (and their mode line equivalents) and it does not > apply to other faces in the header line that may inherit from remapped > faces, so that's good. > > Also, I understand what you're saying that remapping mode-line was decide= d > in Emacs 29 to not be supported and the conclusion may be the same for > header-line. If that's what it needs to be, that's fine. As Eshel said, i= t > will be a breaking change because people have relied on this behavior. > > I think there's no way to support what you expect cleanly. The reason is > simple: inheritance in so-called "basic faces" is not taken into account > when face-remapping is considered for them. Face inheritance is considere= d > when faces are merged, but basic faces are not merged when they are used = by > the display engine for the respective parts of the Emacs display (i.e., t= he > header-line faces for the header line, as opposed to just using the > header-line faces for buffer text). That changing the attributes of the > default faces has the effect of propagating the inheritance through > face-remapping is an accident, the side effect of the particular > implementation of when we recompute all the basic faces anew. It could be > considered a bug on its own. > > We could perhaps add special-purpose code that would consider face > inheritance for mode-line and header-line faces when remapping them, but > that would get is in a different mess: > > . mode-line-inactive inherits from mode-line only by default, on color > displays it doesn't; so if you remap mode-line, mode-line-inactive will > only be affected on monochrome displays > . header-line also inherits from mode-line, albeit only by default, so > remapping mode-line would _sometimes_ affect header-line (and also > header-line-active and header-line-inactive) and sometimes not > . if the user customizes some of the mode-line or header-line faces to no= t > inherit or to always inherit, remapping mode-line or header-line will > produce different results for different faces > > So basically it's a royal mess, all of it caused by the fact that people > somehow expect that remapping the header-line face will affect > header-line-active and header-line-inactive, and similarly for mode-line. > That was never supported for basic faces, and I think it makes little sen= se > to support it in the future, because the results will certainly surprise > someone. > > 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's reasonable to expect that inherit and face remapping would work the same way always. I didn't even know there was a notion of "basic faces" and what that meant. If that's somehow a special designation that confers different behavior, then we shouldn't be surprised if people are confused by its differences. I do not have these differences memorized, and ultimately that's what it sounds like we are being asked to do. Yes, you can remap faces, yes, you can inherit faces, and yes those two work together EXCEPT in this one case. Even with documentation, this will be confusing because we cannot rely on people finding that documentation. If basic faces do not fully support inheritance, we probably shouldn't allow them to have inheritance. That would mean that header-line-inactive would be defined explicitly, without inheritance, and if someone attempted to add an inherit property, it would fail. This would mean that the base faces, header-line and mode-line would be eliminated. Is it too much to ask for someone to explicitly configure the four faces (mode-line-active, mode-line-inactive, header-line-active, and header-line-inactive) any time they want to apply a theme to them? It sounds like that's the expectation for remapping, so why not extend that to customizing them? If there were no header-line or mode-line face then I would not have run into this. I would have been required to update my theme accordingly and the code that I use to remap header line faces, but that would have been apparent and seems like a reasonable change to make in a major version, but I can't recommend any of this because I don't know enough about the version criteria, release process, internals, etc, so please consider this just a perspective. Thanks, --00000000000075d11a06288c62cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 05, 2024 at 12:42 PM, Eli Zaretski= i <eliz@gnu.org> wrote:<= br>

From: Aaron Jensen <aaronjensen@gmail.c= om>
Date: Thu, 5 Dec 202= 4 08:02:06 -0800
Cc: trevor.m.murphy@gmail.co= m, me@eshelyaron.com, 73862@debbugs.gnu.org

On Wed, Dec 04, 2024 at 11:51 PM, Eli Zaretskii <eliz@gnu.org> wrote:

Once again, please show some simple Lisp to reproduce the phenomena you are observing. It is hard to discuss these highly technical issues on this abstract level.

Happy to. Sorry, I didn't think it was necessary given Eshel's prov= iding of the recipe.

I asked a recipe from you because you seemed to be reporting something different: the happening once" part.

1. (setq header-line-format "Some Header")
2. (face-remap-set-base 'header-line 'highlight)
3. (set-face-attribute 'default nil :height (+ (face-attribute 'def= ault
:height) 10))
4. (switch-to-buffer-other-window "new")
5. From within new buffer/window: (set-face-attribute 'default nil
:height (+ (face-attribute 'default :height) 10))

You'll see after step 3 the header line switches to the highlight face. After step 5, the header line in the original buffer switches away from the highlight face, which is unexpected.

Why are you changing the attributes of the default face in step 3 and step 5 when what you want is to change the header-line face? And do you understand why step 2 didn't change the way header line is displayed, but step 3 did?


Only to f= orce a redisplay in a way that actually causes the inheritance to be consid= ered. Note that when you reproduce this same thing with the mode-line, forc= e-mode-line-update doesn't work to cause=C2=A0the inheritance to be con= sidered. There's something "special" about changing the font = or the geometry of the frame or something that's causing the considerat= ion of inheritance.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


If you then switch back to the original buffer and change the font size again, the highlight will display again.

How come the font of the default face affects the colors of the header-line faces? Doesn't that already look strange?

The strange thing is that when and how the inheritan= ce is taken into account is not the same as for other faces. So yes, it alr= eady looks strange =E2=80=94 I shouldn't need to force a redisplay. Aff= ecting the font of the default face is just one means by which I can trigge= r the redisplay in a way that causes the issue. The specifics of it are a r= ed herring. When I first noticed the issue it was as a result of a vterm po= pup window being shown. No default font modifications were made. I don'= t know what the specific trigger was, however.


Switching back to the new buffer and changing the font size causes it to disappear again, so I was mistaken about it only happening once.

OK, so that mystery doesn't exist. Good.

On the very basic level of the display code, when a display iterator is initialized, the window for whose display the iterator is used must be given to init_iterator as its argument, and the buffer of that window must be temporarily made to be the current buffer. So this cannot be the problem in this case. If init_iterator would be passed an incorrect window, we'= d have much more grave display problems than this minor issue.

Understood, but that's not what I was attempting to describe. I was try= ing to say that the window passed to init_interator IS the correct window. And that that is used to resolve the remap for the inactive/active faces. However, it does not appear that that same window is used to resolve remapping of faces that are inherited by the inactive/active faces.

Face remapping is local to buffers, not to windows. So which window is passed to init_interator is not relevant to face remapping; the buffer of that window is.


My mistake= . Even so, the buffer isn't being taken into account consistently, but = you speak to that below.


>From what I can tell, this only applies to header-line-active and header-line-inactive (and their mode line equivalents) and it does not apply to other faces in the header line that may inherit from remapped faces, so that's good.

Also, I understand what you're saying that remapping mode-line was deci= ded in Emacs 29 to not be supported and the conclusion may be the same for header-line. If that's what it needs to be, that's fine. As Eshel s= aid, it will be a breaking change because people have relied on this behavior.

I think there's no way to support what you expect cleanly. The reason is simple: inheritance in so-called "basic faces" is not taken in= to account when face-remapping is considered for them. Face inheritance is considered when faces are merged, but basic faces are not merged when they are used by the display engine for the respective parts of the Emacs display (i.e., the header-line faces for the header line, as opposed to just using the header-line faces for buffer text). That changing the attributes of the default faces has the effect of propagating the inheritance through face-remapping is an accident, the side effect of the particular implementation of when we recompute all the basic faces anew. It could be considered a bug on its own.

We could perhaps add special-purpose code that would consider face inheritance for mode-line and header-line faces when remapping them, but that would get is in a different mess:

. mode-line-inactive inherits from mode-line only by default, on color displays it doesn't; so if you remap mode-line, mode-line-inactive will only be affected on monochrome displays
. header-line also inherits from mode-line, albeit only by default, so remapping mode-line would _sometimes_ affect header-line (and also header-line-active and header-line-inactive) and sometimes not
. if the user customizes some of the mode-line or header-line faces to not inherit or to always inherit, remapping mode-line or header-line will produce different results for different faces

So basically it's a royal mess, all of it caused by the fact that people somehow expect that remapping the header-line face will affect header-line-active and header-line-inactive, and similarly for mode-line. That was never supported for basic faces, and I think it makes little sense to support it in the future, because the results will certainly surprise someone.

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 th= at I agree with this: "...people somehow expect that remapping the hea= der-line face will affect header-line-active and header-line-inactive." I'm not sure why it = wouldn't be expected. It's reasonable to expect that inherit and fa= ce remapping would work the same way always. I didn't even know there w= as a notion of "basic faces" and what that meant. If that's s= omehow a special designation that confers different behavior, then we shoul= dn't be surprised if people are confused by its differences. I do not h= ave these differences=C2=A0memorized, and ultimately that's what it sou= nds like we are being asked to do. Yes, you can remap faces, yes, you can i= nherit faces, and yes those two work together EXCEPT in this one case. Even= with documentation, this will be confusing because we cannot rely on peopl= e finding that documentation.

If basic faces do not fully support inheritance, we probably shouldn&= #39;t allow them to have inheritance. That would mean that header-line-inac= tive would be defined explicitly, without inheritance, and if someone attem= pted to add an inherit property, it would fail.
<= br>
This would mean that the base faces, header-line a= nd mode-line would be eliminated. Is it too much to ask for someone to expl= icitly=C2=A0configure the four faces (mode-line-active, mode-line-inactive,= header-line-active, and header-line-inactive) any time they want to apply = a theme to them? It sounds like that's the expectation for remapping, s= o why not extend that to customizing them?

If there were no header-line or mode-line face then I wo= uld not have run into this. I would have been required=C2=A0to update my th= eme accordingly and the code that I use to remap header line faces, but tha= t would have been apparent and seems like a reasonable change to make in a = major version, but I can't recommend any of this because I don't kn= ow enough about the version criteria, release process, internals, etc, so p= lease consider this just a perspective.

=
Thanks,
--00000000000075d11a06288c62cb--