Re: face-attribute and face-remapping-alist

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 30 Mar 2021 18:53:28 +0000
> From: "gliao.tw@pm.me" <gliao.tw@pm.me>
> 
> The `face-attribute' function defined in `faces.el' is the foundation of many face property inquiry functions such as `face-background'. However, `face-attribute' is not aware of buffer-local variable 'face-remapping-alist' which is used for buffer-specific theming.
> 
> Since there are many modes, such as `term-mode', rely on `face-attribute' to obtain face information while `face-attribute' is only capabale of obtaining frame-specific, rather than buffer-specific face infomation, these modes cannot display faces sufficiently well while a buffer-local theme is applied via `face-remap-add-relative' or `face-remap-set-base' (both functions, defined in `face-remap.el', add items to buffer-specific variable `face-remapping-alist').
> 
> Therefore, I propose the following prototype of an enhanced version of `face-attribute' function that is aware of the existence of `face-remapping-alist' in current buffer and return face property from `face-remapping-alist' instead of  frame-specific (single frame also means global) face property.

Thanks, but unconditionally changing the behavior of face-attribute in
such fundamental ways is a non-starter.  There must be a way to still
get the frame-specific face attributes, un-effected by buffer-specific
remapping.  face-attribute is quite a low-level API, and face
remapping is a higher-level feature.

So if we want face-attribute to pay attention to face remapping, that
must be an optional behavior under control of some optional argument
or a variable that could be let-bound.

Alternatively, we could introduce a new API for what you want.