Re: face-attribute and face-remapping-alist

["gliao.tw@pm.me" <gliao.tw@pm.me>]

[-- Attachment #1: Type: text/plain, Size: 6625 bytes --]

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 <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.

[-- Attachment #2: Type: text/html, Size: 7613 bytes --]