From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: 45264-done@debbugs.gnu.org
Subject: bug#45264: 26.3; `face-remap-set-base' seems to be bugged
Date: Sat, 19 Dec 2020 11:28:31 -0800 (PST) [thread overview]
Message-ID: <8397c6ee-966d-4d34-9a64-2dde3515cedd@default> (raw)
In-Reply-To: <<83a6u9tyh1.fsf@gnu.org>>
> > The confusion is from the doc not saying explicitly
> > that each element of SPECS is a face spec, and NOT a
> > face.
>
> SPECS has no "elements". SPECS stands for arguments to the function
> beyond the 1st arg FACE.
As with any &rest, you supply zero or more actual
args that correspond to SPECS. The function itself
receives a single list argument that corresponds to
SPECS.
In the function body, variable SPECS is a list.
And as the doc says, "Each list element...".
> Each such argument is either a face name or
> a list of attribute/value pairs.
AFAICT, the function doesn't work if such an arg
is a face name. See what I said about that
previously, please.
> I changed the doc string to be more clear about that.
Great. Thanks for taking a look.
Please check for the behavior bug I pointed to:
If the doc is correct then the behavior seems
bugged. It's not true that you can pass face
names, AFAICT.
> > 2. "why you thought the argument could be a list of
> > one or more faces?"
> >
> > The doc string explicitly says that elements of
> > SPECS can be face names:
> >
> > Each list element should be either a face name or...
>
> That's after it says that you should consider SPECS as "forming" a
> list of elements.
"Forming" a list of elements is unclear, as I said.
And SPECS is, itself, from the point of view of the
function, a list of elements. See above. There is
_nothing_ special about this. Every &rest parameter
behaves the same in this regard.
BTW, the exact same misleading and inexact text is
used for function `face-map-add-relative'.
For functions `buffer-face-(set|toggle)', however,
we instead say, as we usually do, "Each argument
in SPECS should be a face, i.e., either a face name
or a property list...". And we explicitly speak of
SPECS as a list (singular): "if SPECS is omitted or
nil..."
next parent reply other threads:[~2020-12-19 19:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <<<dbc9cd7f-c4da-4137-a972-aada49e0f1f1@default>
[not found] ` <<<833602umgb.fsf@gnu.org>
[not found] ` <<4efb5c63-6636-449f-8e2b-4b8533a9cc8c@default>
[not found] ` <<83a6u9tyh1.fsf@gnu.org>
2020-12-19 19:28 ` Drew Adams [this message]
2020-12-19 19:40 ` bug#45264: 26.3; `face-remap-set-base' seems to be bugged Eli Zaretskii
[not found] <<dbc9cd7f-c4da-4137-a972-aada49e0f1f1@default>
[not found] ` <<833602umgb.fsf@gnu.org>
2020-12-19 18:32 ` Drew Adams
2020-12-19 18:58 ` Eli Zaretskii
2020-12-16 0:31 Drew Adams
2020-12-19 10:20 ` 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=8397c6ee-966d-4d34-9a64-2dde3515cedd@default \
--to=drew.adams@oracle.com \
--cc=45264-done@debbugs.gnu.org \
--cc=eliz@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.