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: Thu, 03 Feb 2022 08:53:10 +0200 Message-ID: <83mtj85tm1.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> <83leyu73i8.fsf@gnu.org> <87k0edrvxm.fsf@gnus.org> <83sft15egx.fsf@gnu.org> <871r0loxr9.fsf@gnus.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="29495"; 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 Thu Feb 03 07:56:52 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 1nFW32-0007Sa-IE for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 03 Feb 2022 07:56:52 +0100 Original-Received: from localhost ([::1]:46356 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nFW30-0005vQ-S3 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 03 Feb 2022 01:56:50 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37488) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nFW0I-0005ui-SA for bug-gnu-emacs@gnu.org; Thu, 03 Feb 2022 01:54:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60343) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nFW0I-0003oQ-Fi for bug-gnu-emacs@gnu.org; Thu, 03 Feb 2022 01:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nFW0I-0005il-FS for bug-gnu-emacs@gnu.org; Thu, 03 Feb 2022 01:54: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: Thu, 03 Feb 2022 06:54: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.164387120821942 (code B ref 53636); Thu, 03 Feb 2022 06:54:02 +0000 Original-Received: (at 53636) by debbugs.gnu.org; 3 Feb 2022 06:53:28 +0000 Original-Received: from localhost ([127.0.0.1]:54240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFVzk-0005ho-Hk for submit@debbugs.gnu.org; Thu, 03 Feb 2022 01:53:28 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58942) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFVzh-0005hb-92 for 53636@debbugs.gnu.org; Thu, 03 Feb 2022 01:53:27 -0500 Original-Received: from [2001:470:142:3::e] (port=56504 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 1nFVza-0003kw-1i; Thu, 03 Feb 2022 01:53:18 -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=uoyZm/gvui68yYkOIGgzvTTDxTvlAnvZvKfrKq3p6zY=; b=D9WzqYhyxIxjJxdMoQaP vtolgrQpWfIDSDkgw7jadxQxd+bQMz8LVyYBNXa7Qpjvsev8mZvGnbAmRLwAQjxCy5KGTVgHZm5ih oBg+V1IEXANdg/9RjwTaSAgY4JuUgBR83dth3dqXU9Hzjk0VThuu7WqXc0egQpC33lPdR/7BMMEGb wtHyOtn9QfW842VyO2dsex+rIQzbZBlC84tG/BUg3v18VTiuGIvx9CBmBRrcyKjFTtJhuRi6RLlRF +AOC46zB8qH6YVPVZJoq8uRq+xj8XvWK15OVg0fI4b9Rr/Sj+SUqvlz3s9fbwraRuujmjR8gg5K9V HMs5RskfNvCjNw==; Original-Received: from [87.69.77.57] (port=3418 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 1nFVzO-0007yZ-Gt; Thu, 03 Feb 2022 01:53:08 -0500 In-Reply-To: <871r0loxr9.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 02 Feb 2022 20:48:42 +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:225845 Archived-At: > From: Lars Ingebrigtsen > Cc: 53636@debbugs.gnu.org, tsdh@gnu.org > Date: Wed, 02 Feb 2022 20:48:42 +0100 > > >> OK, you want to change the header-line and mode-line-inactive faces so > >> that they no longer inherit from the mode-line face? > > > > Yes, I think this is the best way forward. Though it will be somewhat > > backward-incompatible, if someone customizes mode-line and expects > > header-line to follow suit. > > I think this would break a lot more than the current situation does. Yes, it will. But if we want to break the link between mode-line and header-line, I see no better way. > Lots of people expect these faces to inherit the way they do, and have > set up stuff based on that. Programmatic remapping of the `mode-line' > face, on the other hand, is a much smaller issue, and we can just say > "use `mode-line-active' instead". That'd be fine with meas well,if it's acceptable. > Note that in the other frame (displaying *Messages*), the > mode-line-inactive face has inherited the underline from line-visited. > (If I select that window, then the mode-line face has not, that is just > in the current buffer.) So remapping a face that has inherited faces > leads to side effects in other places... When you remap a face, the faces that inherit from it are affected only on new frames, because when we create a frame, we recompute the set of the basic faces for it from scratch and thoroughly. That's exactly the other side of the issue which started this discussion: the inheriting faces on the original frame aren't affected by the remapping of the parent face, but those same faces on new frames are. > Anyway, what I was thinking of is a really simple solution: Have > `face-remap-add-relative' loop over all children and remap them, too. > (I haven't actually attempted to write something like that, though. 😀) Why not leave this to the (small number of) applications that want to do this?