Re: face-attribute and face-remapping-alist

[address@hidden]

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.

Pic_1_global_leuven_theme_applied.png
Description: PNG image

Pic_4_buffer_local_aware_fa_ansi_term_and_eshell_consistent.png
Description: PNG image

Pic_3_invalid_local_theme_rendering_in_ansi_term.png
Description: PNG image

Pic_2_local_wombat_theme_applied.png
Description: PNG image