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: Thu, 05 Dec 2024 22:42:58 +0200 Message-ID: <8634j1n9nx.fsf@gnu.org> References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25424"; mail-complaints-to="usenet@ciao.gmane.io" Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org To: Aaron Jensen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 05 21:46:20 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 1tJIjr-0006ML-KD for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Dec 2024 21:46:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tJIjc-0006Vh-Um; Thu, 05 Dec 2024 15:46: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 1tJIja-0006VI-Mx for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2024 15:46: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 1tJIja-0007IQ-F3 for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2024 15:46:02 -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=ZYarllNL1BB6vvongb960gRMktkH2nJbkjDW9SlfoIs=; b=sO2ARfZSw24XLyRbnmWUQ2nLEifr6rqpLzUhNwZKm/emJlCBYFs9GjOlCTrv/67F18eHzDFkKM4ED4Xk39JDg+WZcGsM2ToKZvhu/43cQDzsEHWBQ6HLv49hx/kS7eZPn2tB6rAbG9iqVSLuD3ESd1BkkaJkO2tnxzk0LkHDgAAbRdg/ErKj9MqkMWKvFaxhqfJlGAZG7jrYaf0Fnv8LykGtdIATRip9jrdS4lZiTdq1kyQIb+rNpuiPgA5xLbaFHog19ioQ6E0F25Uzj09YzyzhIHUcsrYmB08+F53ii7OsMsn199F4mJOTCiWfOCMAyi4xRbIWkhYwNtj+kfhK4A==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tJIjZ-0002RO-U6 for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2024 15:46:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Dec 2024 20:46: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.17334315249329 (code B ref 73862); Thu, 05 Dec 2024 20:46:01 +0000 Original-Received: (at 73862) by debbugs.gnu.org; 5 Dec 2024 20:45:24 +0000 Original-Received: from localhost ([127.0.0.1]:41129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJIix-0002QO-Lw for submit@debbugs.gnu.org; Thu, 05 Dec 2024 15:45:24 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50058) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJIiu-0002Q6-CT for 73862@debbugs.gnu.org; Thu, 05 Dec 2024 15:45:22 -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 1tJIgh-0006eU-SP; Thu, 05 Dec 2024 15:43:03 -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=ZYarllNL1BB6vvongb960gRMktkH2nJbkjDW9SlfoIs=; b=o/vWn4lcgXbV wZ0FaaUIBPBCYu498+HqRVCJrN02forIWC0G1R4a1uVOYnyAUVPeyYeEjUCkMoMbVdaFS0uDy6qCu BybKi+lB90EdqnzldK0+yP8AcAolUmzGTUdDfyqfjz2AGla49PUk1ygihNdk1n4rG1zfhpcwqa+/E EuIqJ9B3xZVcq9DOGCoXnDZec4/itdyhEr3A+yGlaC1NAAzuCpSpOStx8OBupSF7vNIxHurMi1aVi ptWAkWlItyj3YVtcOdS3j+tsZQASKp2f3yNNy22BZ+8yMTGrOKdEh+CCRwEM7vywsfWMEP0SePHsC 1MlOqKK6Nir75G2L0R3kUw==; In-Reply-To: (message from Aaron Jensen on Thu, 5 Dec 2024 08:02:06 -0800) 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:296483 Archived-At: > 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 this > > 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 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? > 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? > 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 trying > 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. > 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 decided > 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, 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 into 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.