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: Tue, 01 Feb 2022 22:09:35 +0200 Message-ID: <83leyu73i8.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> <835ypz8zbm.fsf@gnu.org> <87fsp2v0ky.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34505"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53636@debbugs.gnu.org, tsdh@gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 02 00:58:35 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 1nF32g-0008mA-FB for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Feb 2022 00:58:34 +0100 Original-Received: from localhost ([::1]:35042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nF32f-0003Vn-0C for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Feb 2022 18:58:33 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40868) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nEzUU-0005RV-Ks for bug-gnu-emacs@gnu.org; Tue, 01 Feb 2022 15:11:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51323) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nEzUU-0008FC-AP for bug-gnu-emacs@gnu.org; Tue, 01 Feb 2022 15:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nEzUU-0001bl-6u for bug-gnu-emacs@gnu.org; Tue, 01 Feb 2022 15:11: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: Tue, 01 Feb 2022 20:11: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.16437462086087 (code B ref 53636); Tue, 01 Feb 2022 20:11:02 +0000 Original-Received: (at 53636) by debbugs.gnu.org; 1 Feb 2022 20:10:08 +0000 Original-Received: from localhost ([127.0.0.1]:44222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEzTb-0001a7-K5 for submit@debbugs.gnu.org; Tue, 01 Feb 2022 15:10:07 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEzTZ-0001ZV-Vm for 53636@debbugs.gnu.org; Tue, 01 Feb 2022 15:10:06 -0500 Original-Received: from [2001:470:142:3::e] (port=46920 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 1nEzTA-0007mt-EM; Tue, 01 Feb 2022 15:10:00 -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=7L28qOOkcOMwdlUXoFe6dvy7EY9DuT4ZkaTzuQiQACI=; b=d68JGj0FgHQd wz2DB8HiAyZ11iWOxXmzchUlT+1Aqwdv2CZxKWbnfQ51iUGbxntFeQUGdkyozu4JVeeIBHn0m9zKJ PyGjqNiQWEWt0M7C28XzoPDEEKtQY5PT4im9pwFlANCB8Yfz9Xf3WL8xMsGg38LR1KodhjiBp/e2O sQg3nT6GxIDTbJDhqaycQdhYLEunm/WMkXi6OCwyh1UHU3vny1BtWUtUgJpReH/DwHm2GN7fw04I0 vutGqWzT9kD91s2d4T6C23nH6zlARPtDBno9WqlK5k50sRWnc0K1tePmQvwNIzr/bwSS5ogtCEdvy 2Mw3WS35UkzYAqOReJ7/iQ==; Original-Received: from [87.69.77.57] (port=2912 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 1nEzT5-0000Q8-T2; Tue, 01 Feb 2022 15:09:37 -0500 In-Reply-To: <87fsp2v0ky.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 01 Feb 2022 20:38:53 +0100) 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:225766 Archived-At: > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Tue, 01 Feb 2022 20:38:53 +0100 > > Eli Zaretskii writes: > > > 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. > > But this is a bug, I think? You can see the same effect in Emacs 28 if > you do: > > (face-remap-add-relative 'mode-line 'link-visited) What do you suggest instead? to treat some basic faces specially because we happen to know that they inherit from other basic faces? That's ugly and fragile. If we want to solve this cleanly and radically, I'd prefer to break the vicious circle by removing the inheritance from basic faces altogether. The basic faces are just that: they aren't supposed to inherit from other basic faces. That would also decouple header-line and everything else as a side effect. > Making face remapping work reliably for these faces would be better, but > I haven't looked at the code. Maybe you will see something I don't, but in general face remapping isn't magical, we must explicitly account for it where it might matter, or it will not work. After all, all face remapping does is add some members to a list, it doesn't actually change any faces. So we need to do stuff like this: if (! NILP (Vface_remapping_alist)) remapped_base_face_id = lookup_basic_face (w, XFRAME (w->frame), base_face_id); That's how face-remapping-alist takes its effect. If you want this to work for inherited faces, you must do this for the parent face, recursively, before you do it for the face in which you are interested. You want to add the inheritance-chasing loop to basic face look up? I don't.