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.devel Subject: Re: face-attribute and face-remapping-alist Date: Thu, 01 Apr 2021 10:08:04 +0300 Message-ID: <83sg4ah48b.fsf@gnu.org> References: <834kgsjwdf.fsf@gnu.org> <8335wcjvzh.fsf@gnu.org> <83sg4bizbr.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8127"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: "gliao.tw@pm.me" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 01 09:08:58 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lRrRm-0001tl-BM for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Apr 2021 09:08:54 +0200 Original-Received: from localhost ([::1]:51198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRrRl-00058T-DU for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Apr 2021 03:08:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48606) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lRrRI-0004ja-3x for emacs-devel@gnu.org; Thu, 01 Apr 2021 03:08:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49192) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRrRG-0008WE-Ut; Thu, 01 Apr 2021 03:08:22 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4340 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRrRG-0004em-7V; Thu, 01 Apr 2021 03:08:22 -0400 In-Reply-To: (gliao.tw@pm.me) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267235 Archived-At: > Date: Wed, 31 Mar 2021 22:41:24 +0000 > From: "gliao.tw@pm.me" > Cc: "emacs-devel@gnu.org" > > Therefore, to make `ansi-term' receive correct face information, > we need to > > 1. change 'face-attribute' to make it aware of `face-remapping-alist' > in a way that is similar to my earlier proposal; or > > 2. do not change any existing face-related functions but define new > functions to retrieve buffer-local face settings such like 3. do not change any existing face-related functions but look up the relevant face in face-remapping-alist before calling face-attribute. > So my question here is that which of the following options > > 1. make `face-attribute' return buffer-local face attributes if the face has been > customized (via `face-remapping-alist) in that buffer otherwise return > frame-local face attributes > 2. Introducing new face attribute getting/setting APIs to Emacs code base; > these new APIs are `face-remapping-alist' aware and use unchanged > `face-attribute' as the fallback dispatch option > 3. Do nothing to Emacs code base: let the library/package developer to decide > whether buffer local face settings should be accommodated or not > > is the most economical one? "Economical" in what sense? Changing long-standing default behavior of face-attribute is out of the question: we cannot make such changes in such old APIs. Item 3 is so easy to implement in those packages that really want to cater to buffer-local face customizations is so easy that I see no need for any change in core. Which then makes option 3 "the most economical" from my POV. And that's even before we discussed whether sensitivity to buffer-local face changes is at all a good idea in general, something that I'm not at all convinced in. Faces are more often than not related to major and minor modes, so having them change depending on buffer-local customizations would mean 2 buffers under the same mode will look differently. Why is that a good idea?