Eli, thanks for the comments and questions. I would like to ues the following an example to expalint why I want to propose such a change in `face-attribute'. * The issue In the following emacs lisp transcript, I set `leuven' as the global theme and load but not yet enable `tango' theme, and then ask for its `default' face attributes under `leuven' globla them. The corresponding display are shown in attacthed "Pic_1_global_leuven_theme_applied.png". (load-theme 'leuven t nil) (load-theme 'tango t t) (face-attribute 'default :background) (face-attribute 'default :foreground) Next, I set the `ielm' buffer's default face using `wombat' theme's `default' face via `face-remap-add-relative' and inquire the 'default' face's foreground and background via `face-attribute` again using the following command: (face-attribute 'default :background) (face-attribute 'default :foreground) As we can see the results shown in the attached "Pic_2_local_wombat_theme_applied.png", although the backgound and foreground have been changed according to `wombat' theme's settings , but `face-attribute' function still returns the 'default face attribute of `leuven', instead of `wombat' theme's. 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 with a theme in buffer-local manner via functions implemented in `face-remap.el'. Another aspect of this issue is that many modes rely on `face-attribute' to obtain appropriate face setting and it is known that `face-attribute' is unlikely to return correct results in buffer whose appearence is specificed by buffer-local `face-remapping-alist'. The following code are extracted from `term.el', which shows a heavy dependency on `face-attribute'-based `face-foreground` and `face-background' functions to extract face information. (setq term-current-face (list :foreground (face-foreground (elt ansi-term-color-vector term-ansi-current-color) nil 'default) :background (face-background (elt ansi-term-color-vector term-ansi-current-bg-color) nil 'default) :inverse-video term-ansi-current-reverse)) In the attacched "Pic_3_invalid_local_theme_rendering_in_ansi_term.png" screenshot, we can see that `ansi-term' from `term.el' is unable to render buffer local theme properly (the top) while eshell (the bottom) is able to render the buffer local color theme (relatively) properly. * Potential solutions/directions The following table summarizes some directions/solutions I can think of at the time being: |-------------------------+---------------+-----------------| | Approach | Benefit | Risk / Cost | |-------------------------+---------------+-----------------| | make `face-attribute' | No need | (Potentially) | | `face-remapping-alist'- | to change | mix frame-local | | aware | any exisitng | and buffer- | | | libraries/ | local settings | | | packages | | | | | | |-------------------------+---------------+-----------------| | New Emacs APIs that are | No changes | Require porting | | `face-remapping-alist'- | in existing | efforts from | | aware, potentially use | Emacs API | libraries / | | current | | packages | | `face-attribute' as the | | developers; | | fallback option | | marketing cost | | | | on the new APIs | | | | | |-------------------------+---------------+-----------------| | No change in Emacs at | Users pay | Current issues | | all: package/library | as they go: | remain; wild | | developers come up with | spend your | west of wheel | | their own solutions to | own resources | re-invention. | | deal with buffer-local | on features | | | face setting | you want. | | | | | | |-------------------------+---------------+-----------------| The above table just represents my current best, and definitely incomprehensive, thoughts on how can we make buffer-local face setting functions and face information functions work more consistently. The attached "Pic_4_buffer_local_aware_fa_ansi_term_and_eshell_consistent.png" shows a result using appoarch #1. The top `eshell' buffer and bottom `ansi-term' buffer can have very cosistent (although some difference in bold face), almost identical appearence with same buffer-local theme applied. Compare to "Pic_3_invalid_local_theme_rendering_in_ansi_term.png", we can see approach #1 does yield some favorable results (comes with the risk stated in above tabel). I hope above material can do some little help in clarifying my questions and thoughts on issues caused by current `face-remapping-alist'-unaware implementation of `face-attribute'. Any comments are greatly appreciated. Thanks, Kiong-Gē. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, March 30, 2021 2:13 PM, Eli Zaretskii wrote: > > Date: Tue, 30 Mar 2021 22:05:00 +0300 > > > From: Eli Zaretskii eliz@gnu.org > > Cc: emacs-devel@gnu.org > > 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. > > And btw, I don't really understand the difficulty: fetching the > remapped face from face-remapping-alist is trivial. Thereafter, > face-attribute will do what you want. So I don't even think I > understand the problem you are trying to solve. I guess a detailed > description of some specific example would help here. > > In any case, please don't forget that frame-local and buffer-local > values cannot be intermixed without producing undesirable effects. > Face remapping was introduced to allow finer resolution in face > attributes than the per-frame one, under the control of the > application. Your proposal pushes the buffer-local aspects to the > lower levels, and out of the application's control, which I don't > think is TRT.