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 <eliz@gnu.org> 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.