From: Eli Zaretskii <eliz@gnu.org>
To: gliao.tw@pm.me
Cc: emacs-devel@gnu.org
Subject: Re: face-attribute and face-remapping-alist
Date: Tue, 30 Mar 2021 22:13:22 +0300 [thread overview]
Message-ID: <8335wcjvzh.fsf@gnu.org> (raw)
In-Reply-To: <834kgsjwdf.fsf@gnu.org> (message from Eli Zaretskii on Tue, 30 Mar 2021 22:05:00 +0300)
> 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.
next prev parent reply other threads:[~2021-03-30 19:13 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 [this message]
2021-03-31 3:05 ` gliao.tw
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=8335wcjvzh.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=gliao.tw@pm.me \
/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.