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: Fri, 06 Dec 2024 10:55:22 +0200 Message-ID: <86jzcdkx6t.fsf@gnu.org> References: <86wmgfzhgc.fsf@gnu.org> <86zflay7hh.fsf@gnu.org> <86jzcey3cu.fsf@gnu.org> <8634j1n9nx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2207"; mail-complaints-to="usenet@ciao.gmane.io" Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org To: Aaron Jensen , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 06 09:56:19 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 1tJU8I-0000Mp-PA for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 06 Dec 2024 09:56:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tJU84-0003fX-8J; Fri, 06 Dec 2024 03:56:04 -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 1tJU82-0003fM-T4 for bug-gnu-emacs@gnu.org; Fri, 06 Dec 2024 03:56: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 1tJU82-00038z-Kg for bug-gnu-emacs@gnu.org; Fri, 06 Dec 2024 03:56:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=i4L5Treff/yK8L29yjAyw87b9gQwKLcgCndEQ509em8=; b=Gxt1ZyjtZ4tGIhkipn09FceFphIG5fBkeGyJJn6Wh+h6O6pN4MKIAhq/8PDn+yEgM7U+0JRi54aW1rbwnW17hbtbzXds2rmBWJb8EJFhT5XbwTLkGArl0O0qyONzIUaZ7f1sEruaR6yoyrnXM44Okcdo/kBf3ys4ZySJYgb3aPe8H2Frqj7hcGgPQ3CQTE9eR1mG1sHTEt3t/WDu02sL188alQwd875NPLPTmk1UsvCmDOFrqHBDTlbFJ7q9aWozNCnytC91x/6Y0/Qo7IPi1olMxJxW+vDBoqcl+0VtBjLHP64CYk5ZFNhvLu9POp5Sh/lSW9Jw51zbcC/74GmW3w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tJU81-0004Ua-Kg for bug-gnu-emacs@gnu.org; Fri, 06 Dec 2024 03:56: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: Fri, 06 Dec 2024 08:56: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.173347533817227 (code B ref 73862); Fri, 06 Dec 2024 08:56:01 +0000 Original-Received: (at 73862) by debbugs.gnu.org; 6 Dec 2024 08:55:38 +0000 Original-Received: from localhost ([127.0.0.1]:41999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJU7d-0004Tm-Ei for submit@debbugs.gnu.org; Fri, 06 Dec 2024 03:55:38 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJU7b-0004TT-7Z for 73862@debbugs.gnu.org; Fri, 06 Dec 2024 03:55:36 -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 1tJU7T-000379-Eo; Fri, 06 Dec 2024 03:55:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=i4L5Treff/yK8L29yjAyw87b9gQwKLcgCndEQ509em8=; b=ErLx6vxqoQ2VObqP1gVP VisGGQXXd1OHG+FpbBtrHanuBsVXcGCRQlPomkRSZ2Aszcl1uizIAKrYxf9bKQXMFmrVe/+sdMbVV J+H3kCGIgnA+CTF920bKVHSkqJsdIOUjlgs6IQeJ2Unz1aOavGTfFtu1vg/8VGUcePX6p1wficNmd qM+vr9qGuE37yfPU2WYCNwtlZgGtefOEUQsvwMpN9xkBw6PzhSx6UkFAPCS4tT6uLRPtephMJ54Gb mpLTNoh40i+bYDVONach5QNBzetwiGL+kjipT6mDTmEb8+af5CufEGYLZtewEKJiJCoC+SsHxibMx oDBwGvJ58ZUwug==; In-Reply-To: (message from Aaron Jensen on Thu, 5 Dec 2024 13:14:32 -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:296496 Archived-At: > From: Aaron Jensen > Date: Thu, 5 Dec 2024 13:14:32 -0800 > Cc: trevor.m.murphy@gmail.com, me@eshelyaron.com, 73862@debbugs.gnu.org > > > 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 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. That's because changing the default face causes recomputation of all the faces, starting from the basic faces. It is not directly related to redisplay (which is why force-mode-line-update doesn't have that effect), although, of course, the recomputation is triggered by the next redisplay cycle. > > 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 — 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. See above: I hope the situation is more clear now. > > 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. > It's reasonable to expect that inherit and face remapping > would work the same way always. It doesn't, and never was. The current implementation of faces has a built-in assumption that basic faces don't inherit from any other faces, except the (implicit) inheritance from the default face. So face-remapping of basic faces doesn't take inheritance into account, and never did. > I didn't even know there was a notion of "basic faces" and what that > meant. As a Lisp programmer, you aren't supposed to know that, or care. The problem here is that, by making some basic faces inherit from other faces, we caused this abstraction to leak. > If basic faces do not fully support inheritance, we probably shouldn't > allow them to have inheritance. Yes. But that train has left the station, unfortunately, and quite a long time ago. I don't think there's a way back. Note that mode-line-inactive was originally introduced _in_addition_ to mode-line (which was then used only for the "active" mode-line), so people were expected to customize/remap that new face _in_addition_ to mode-line. It's when we introduced mode-line-active, which _always_ inherits from mode-line, that this problem was first introduced. And now the two header-line faces, which basically repeat the same paradigm, added yet another group of problems. > 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. 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. > 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. > 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? Remapping and customizing are two different customizations, though. They don't have to work the same. > If there were no header-line or mode-line face then I would not have run > into this. Yes, but removing a face from Emacs is a much more significant backward incompatibility than the problems discussed in this bug. I added Stefan to this discussion, in the hope that he could have some suggestions or comments.