Re: face-attribute and face-remapping-alist

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 31 Mar 2021 22:41:24 +0000
> From: "gliao.tw@pm.me" <gliao.tw@pm.me>
> Cc: "emacs-devel@gnu.org" <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?