From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "gliao.tw@pm.me" Newsgroups: gmane.emacs.devel Subject: Re: face-attribute and face-remapping-alist Date: Wed, 31 Mar 2021 22:41:24 +0000 Message-ID: References: <834kgsjwdf.fsf@gnu.org> <8335wcjvzh.fsf@gnu.org> <83sg4bizbr.fsf@gnu.org> Reply-To: "gliao.tw@pm.me" Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34296"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 01 00:42:49 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 1lRjY1-0008rm-1u for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Apr 2021 00:42:49 +0200 Original-Received: from localhost ([::1]:51680 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRjY0-0007Ar-2z for ged-emacs-devel@m.gmane-mx.org; Wed, 31 Mar 2021 18:42:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46212) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lRjWo-0006X1-70 for emacs-devel@gnu.org; Wed, 31 Mar 2021 18:41:34 -0400 Original-Received: from mail-40136.protonmail.ch ([185.70.40.136]:45939) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lRjWl-0001r0-7Q; Wed, 31 Mar 2021 18:41:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail; t=1617230485; bh=hr050DCnuKY2hZByfpMP7bQ0MZ47Vdf9Rrdjaperz5k=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=A3KZO12h3jgR8vMY4atdAfERX6JYO/+NIfNdBJcartaeMpJMUlGfnRjgpUrjPsFPT jTjbuFVDEng86rjJYFxhGMmEjXKD1gdJZfclzymsrxPdR4kvKFaA2Q3IcoppkIxNZs bCxV7njOiAPZ3xl9MakVxknkxjXURWigdRnRdU/zrzIOyu/R4Di9rhO2H95RdsOFHQ xqvgUo5SRO4bFz2xV3Mq7IsGmDyjsDL9QDaosqqeISbsvA3SDjrITAc29bNdTQvO3I n+EXPPXIxESgm42eT4YyK7+CAmh7es/q37Dd66GIwpGCZORJ1iY5y3R9EW59eUJ1hO uIYIYYBsFWG6Q== In-Reply-To: <83sg4bizbr.fsf@gnu.org> Received-SPF: pass client-ip=185.70.40.136; envelope-from=gliao.tw@pm.me; helo=mail-40136.protonmail.ch X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:267226 Archived-At: #+begin_src emacs-lisp (setq term-current-face =09 (list :foreground =09=09 (face-foreground =09=09 (elt ansi-term-color-vector term-ansi-current-color) =09=09 nil 'default) =09=09 :background =09=09 (face-background =09=09 (elt ansi-term-color-vector term-ansi-current-bg-color) =09=09 nil 'default) =09=09 :inverse-video term-ansi-current-reverse)) #+end_src And we already know that if an `ansi-term' buffer has its `term-color-*' faces have been customized through `face-remap-add-relativ= e', `face-foreground' and `face-background' in above code won't return correct face information due to `face-attribute' is not aware of the `ansi-term' buffer's `face-remapping-alist' local variable. 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 #+begin_src emacs-lisp (defun face-attribute-blfa (face attribute &optional frame inherit buffer= ) "Get face attribute with buffer-local faces aware" ;; retrieve buffer-local `face-remapping-alist', if it exists (or (let ((bl-fra (buffer-local-value =09=09 'face-remapping-alist =09=09 (or (and buffer (get-buffer buffer)) =09=09=09 (current-buffer))))) =09 (and bl-fra =09 (plist-get (car (alist-get face bl-fra)) attribute))) =09(face-attribute face attribute frame inherit))) (defun face-foreground-blfa (face &optional frame inherit buffer) (face-attribute-blfa face :foreground frame inherit buffer)) (defun face-background-blfa (face &optional frame inherit buffer) (face-attribute-blfa face :background frame inherit buffer)) (setq term-current-face =09(list :foreground =09 (face-foreground-blfa =09 (elt ansi-term-color-vector term-ansi-current-color) =09 nil 'default) =09 :background =09 (face-background-blfa =09 (elt ansi-term-color-vector term-ansi-current-bg-color) =09 nil 'default) =09 :inverse-video term-ansi-current-reverse)) #+end_src As mentioned in my previous mails, introducing new APIs (without changing e= xisting `face-attribute'-based functions) to make buffer-local faces work sufficien= tly well in various modes do require library/package developers to adapt the new APIs a= nd change, potentially considerable, part of their existing code base to accommodate t= hat. So my question here is that which of the following options 1. make `face-attribute' return buffer-local face attributes if the face ha= s 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 dec= ide whether buffer local face settings should be accommodated or not is the most economical one? I personally believe the option #1 is the most favorable one because, ideal= ly, `face-attribute' should always return face attributes those are consistent = with what have been rendered in any given buffer. Also, this option does not req= uire changing any existing code base of libraries/packages/modes those manipulat= e faces (for example, `term.el'). However, I don't know how much risk of potential breakage brought by option #1. Therefore, we may treat this optio= n as a convenient (only need to change `face-attribute') but also a dangerous= one. Option #2 is an acceptable choice to me although it require porting efforts from the mode/library/package developers to adapt new APIs in Emacs, but at least we have an official APIs that can be used by all Emacs library= /package developers without re-inventing wheels. Option #3 is the least favorable option to me, as it requires developers to= come up with lots of solutions just to solve the common problem of retrieving face information those are consistent with what have been rendered in any given buffers. This wild west approach seems not helpful in solving the problem. Thanks. Kiong-G=C4=93. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Wednesday, March 31, 2021 1:58 AM, Eli Zaretskii wrote: > > Date: Wed, 31 Mar 2021 03:05:42 +0000 > > > From: "gliao.tw@pm.me" gliao.tw@pm.me > > Cc: "emacs-devel@gnu.org" emacs-devel@gnu.org > > > > > From the above example, we can see that `face-attribute' will return = results *incosistent* with what we see in a buffer which has been updated w= ith a theme in buffer-local manner via functions implemented in`face-remap.= el'. > > Sure, but the only change needed in all the cases you described in > order to return attributes that are aware of the remapping is to look > up the face in face-remapping-alist, before calling face-attribute. > This solution is so easy that I don't understand the need for changing > the behavior of face-attribute in such fundamental and incompatible > ways to produce the same effect. > > Am I missing something?