unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.



  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).