From: "gliao.tw@pm.me" <gliao.tw@pm.me>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: face-attribute and face-remapping-alist
Date: Wed, 31 Mar 2021 03:05:42 +0000 [thread overview]
Message-ID: <UPV6ZuVvnhNZ5ptm8_BYi_9ElrzJyGuu6W_Evgm05CShNeLiK0mhjipkOcUSLI_Yne26QtAbZxBrb9GDqT6wkgRjeCuVU88BjmxM4BSwmGk=@pm.me> (raw)
In-Reply-To: <8335wcjvzh.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 7097 bytes --]
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: Pic_1_global_leuven_theme_applied.png --]
[-- Type: image/png, Size: 49079 bytes --]
[-- Attachment #3: Pic_4_buffer_local_aware_fa_ansi_term_and_eshell_consistent.png --]
[-- Type: image/png, Size: 23160 bytes --]
[-- Attachment #4: Pic_3_invalid_local_theme_rendering_in_ansi_term.png --]
[-- Type: image/png, Size: 26768 bytes --]
[-- Attachment #5: Pic_2_local_wombat_theme_applied.png --]
[-- Type: image/png, Size: 73758 bytes --]
next prev parent reply other threads:[~2021-03-31 3:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-30 18:53 face-attribute and face-remapping-alist gliao.tw
2021-03-30 19:05 ` Eli Zaretskii
2021-03-30 19:13 ` Eli Zaretskii
2021-03-31 3:05 ` gliao.tw [this message]
2021-03-31 3:34 ` gliao.tw
2021-03-31 6:58 ` Eli Zaretskii
2021-03-31 13:00 ` Clément Pit-Claudel
2021-03-31 13:27 ` Eli Zaretskii
2021-03-31 22:41 ` gliao.tw
2021-04-01 7:08 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='UPV6ZuVvnhNZ5ptm8_BYi_9ElrzJyGuu6W_Evgm05CShNeLiK0mhjipkOcUSLI_Yne26QtAbZxBrb9GDqT6wkgRjeCuVU88BjmxM4BSwmGk=@pm.me' \
--to=gliao.tw@pm.me \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.