Sorry, in the first example, tango theme should be wombat theme. Sent from ProtonMail mobile -------- Original Message -------- On Mar 30, 2021, 22:05, gliao.tw@pm.me wrote: > 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.