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#53636: 29.0.50; face-remapping broken on master Date: Mon, 31 Jan 2022 21:44:45 +0200 Message-ID: <835ypz8zbm.fsf@gnu.org> References: <87o83tib13.fsf@gnu.org> <871r0p9l4f.fsf@gnus.org> <83ee4p9izg.fsf@gnu.org> <87mtjd8485.fsf@gnus.org> <83a6fd9glm.fsf@gnu.org> <835yq19dk1.fsf@gnu.org> <87czk97yt6.fsf@gnus.org> <8335l49jwu.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6667"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53636@debbugs.gnu.org, tsdh@gnu.org To: larsi@gnus.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 31 20:55:59 2022 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 1nEcmL-0001Sf-DW for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Jan 2022 20:55:57 +0100 Original-Received: from localhost ([::1]:40958 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nEcmJ-0003Lp-Qi for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Jan 2022 14:55:55 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37478) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEcbm-0008Aw-Nm for bug-gnu-emacs@gnu.org; Mon, 31 Jan 2022 14:45:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48115) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nEcbm-0008Rv-Cv for bug-gnu-emacs@gnu.org; Mon, 31 Jan 2022 14:45:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nEcbm-0001Qj-BN for bug-gnu-emacs@gnu.org; Mon, 31 Jan 2022 14:45:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Jan 2022 19:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 53636-submit@debbugs.gnu.org id=B53636.16436583005478 (code B ref 53636); Mon, 31 Jan 2022 19:45:02 +0000 Original-Received: (at 53636) by debbugs.gnu.org; 31 Jan 2022 19:45:00 +0000 Original-Received: from localhost ([127.0.0.1]:41018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEcbk-0001QH-ID for submit@debbugs.gnu.org; Mon, 31 Jan 2022 14:45:00 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEcbi-0001Q2-F2 for 53636@debbugs.gnu.org; Mon, 31 Jan 2022 14:44:58 -0500 Original-Received: from [2001:470:142:3::e] (port=53670 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEcbb-0008PT-L2; Mon, 31 Jan 2022 14:44:53 -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=A+Lp815Y1108hIJcSfj5UCUgJAKCvWe124K7qbKGtRg=; b=UDiXmRs+oNqP XVAriaV5lKnNSUPvpBeYuG9Tsa43wWQ5x/ede3RSZIGzJmMDa7ZBnq2JZ6d5C1+eBHfaeIsQHkM5W McBAju2dIuNlpFrkaCWFEvoVo9k7jvVZAO/tfjto/E4N/j5z5VsJi9ioOzSN3/+HIo08ZEls95jkl QhNigPMcogQvjiN/I0edDRkQPuqSfAtIZ2ejdofUB/WEXOj+O/ENrhc0zK+BerqSW+LyjVP2C2mxp CPkmi97r58UWY7qRoYCBqDtSexsnuXj9WG9eJuy1mb9NvfE/ZBCDt9P942RPD1qXkeEq7/lKLiID0 8LM6nrf5H1QtrQ5fo+Rq4g==; Original-Received: from [87.69.77.57] (port=4568 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEcbZ-0007uI-Dn; Mon, 31 Jan 2022 14:44:50 -0500 In-Reply-To: <8335l49jwu.fsf@gnu.org> (message from Eli Zaretskii on Mon, 31 Jan 2022 14:20:01 +0200) 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" Xref: news.gmane.io gmane.emacs.bugs:225722 Archived-At: > Date: Mon, 31 Jan 2022 14:20:01 +0200 > From: Eli Zaretskii > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > > > From: Lars Ingebrigtsen > > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > > Date: Sun, 30 Jan 2022 21:28:53 +0100 > > > > Eli Zaretskii writes: > > > > > Do we still need the mode-line as a parent of these two faces, or can > > > we go back to what we had before the variable-pitch mode-line changes? > > > > The plan is to reintroduce the variable-pitch stuff after we've ironed > > out the width issues, so I'd rather keep the faces as is. (And I think > > it makes more sense conceptually, since `mode-line' is also used as the > > parent of other faces, like `header-line'.) > > OK, I will see what I can do. Basically, the problem is that mode-line is a well-known face name, and so it can be expected that user customizations and Lisp packages rely on the fact that remapping or otherwise tweaking that face directly affects the display of the mode line of the selected window. So when we effectively renamed mode-line to mode-line-active, we broke compatibility, since in some situations, such as the one described here, what was previously done with the mode-line face must now be done with mode-line-active face. Is that analysis correct, or am I missing something? If so, my suggestion is: . rename mode-line-active back to mode-line . introduce a new face, mode-line-base, say, from which mode-line will inherit, like mode-line-active now inherits from mode-line Then all the tricks people play with the mode-line face will work again, and we can warn not to rely on remapping mode-line-base to automatically affect the mode lines of the currently selected frame. Since this is a new face, we don't need to worry about code out there which already remaps that face. But making this new mode-line-base face use variable-pitch, for example, will still produce the same effect that we had with mode-line a few weeks before. Would that be an acceptable solution? (I considered alternatives, but they are all uglier. Basically, the "basic faces" aren't supposed to inherit from other faces, for face remapping to work as expected.)