From: Gregory Heytings <gregory@heytings.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 57499@debbugs.gnu.org
Subject: bug#57499: Documentation bug in the docstring of set-face-attribute?
Date: Wed, 31 Aug 2022 21:13:58 +0000 [thread overview]
Message-ID: <534c9018d2f901e88b93@heytings.org> (raw)
In-Reply-To: <83czcgry5f.fsf@gnu.org>
>
> I don't see the difference between my text and these two variants. Why
> repeat that the value `unspecified' is a symbol `unspecified'? We never
> say such tautological things in doc strings.
>
I just want to make it as clear as possible that to get that special value
`unspecified' one should use the symbol 'unspecified. That might be
unclear, because after using nil describe-face also displays
`unspecified'.
I bet that what happened with both Damien and Joost is that they wanted to
unset the background/foreground color of a face, they tried to use nil
(because that's the typical value one would use everywhere else in Elisp),
and it seemed to work: describe-face said the attribute was "unspecified",
and the visual effect was also that of an "unspecified" attribute. Later
they discovered that for new frames it didn't work.
>
> Read the discussion in bug#54156 again! That's what it was about.
>
> Or read the code in xfaces which deals with value of unspecified when
> FRAME = t -- it doesn't just store the symbol 'unspecified' in the
> face's attribute, it does something more sneaky. And it interprets nil
> as unspecified in some cases, but not in others.
>
> People stumble on these subtleties all the time, and the advice to use
> an explicit separate call with FRAME = t in the current doc string was
> intended to prevent that. And note that it did work in Joost's case: he
> maybe didn't fully understand _why_ he needs to do it, but he did
> understand _how_ to do what he wanted. Now we want to take that out,
> because it hurts our excessive sense of rigor, and we will get the same
> confusion back...
>
Hmmm... Joost's conclusion was that using frame = nil and 'unspecified
solved his problem, and that he would do that.
Just to be clear: I certainly do not want to take anything out. I simply
do not understand (neither by testing nor by reading the code) what
(set-face-attribute 'some-face t :some-attribute 'unspecified)
does when
(set-face-attribute 'some-face nil :some-attribute 'unspecified)
has already been executed. And in fact that's how this bug report
started: I asked whether anyone could come up with a scenario that would
make the effect of that call with frame = t apparent.
If there are cases where frame = t does something more, then clearly that
information should stay in docstring. My reading of the code is that it
doesn't do anything more, because calling set-face-attribute with nil
implies that Finternal_set_lisp_face_attribute is called with frame = 0,
which in turn implies that Finternal_set_lisp_face_attribute is
(recursively) called with frame = t.
next prev parent reply other threads:[~2022-08-31 21:13 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-31 8:14 bug#57499: Documentation bug in the docstring of set-face-attribute? Gregory Heytings
2022-08-31 8:17 ` Gregory Heytings
2022-08-31 11:11 ` Eli Zaretskii
2022-08-31 12:04 ` Gregory Heytings
2022-08-31 12:39 ` Eli Zaretskii
2022-08-31 12:53 ` Gregory Heytings
2022-08-31 13:06 ` Eli Zaretskii
2022-08-31 13:43 ` Gregory Heytings
2022-08-31 16:11 ` Eli Zaretskii
2022-08-31 18:33 ` Gregory Heytings
2022-08-31 19:13 ` Eli Zaretskii
2022-08-31 19:33 ` Gregory Heytings
2022-08-31 19:49 ` Eli Zaretskii
2022-08-31 21:13 ` Gregory Heytings [this message]
2022-09-01 7:04 ` Eli Zaretskii
2022-09-01 8:25 ` Gregory Heytings
2022-09-01 8:44 ` Eli Zaretskii
2022-09-01 9:02 ` Gregory Heytings
2022-09-01 11:33 ` Eli Zaretskii
2022-09-01 11:56 ` Gregory Heytings
2022-09-01 12:08 ` Eli Zaretskii
2022-09-01 13:15 ` Gregory Heytings
2022-09-01 14:56 ` Eli Zaretskii
2022-09-01 17:07 ` Gregory Heytings
2022-09-01 18:24 ` Eli Zaretskii
2022-09-01 19:35 ` Gregory Heytings
2022-09-02 16:00 ` Eli Zaretskii
2022-09-02 20:48 ` Gregory Heytings
2022-09-03 6:00 ` Eli Zaretskii
2022-09-03 6:43 ` Gregory Heytings
2022-09-03 1:26 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
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=534c9018d2f901e88b93@heytings.org \
--to=gregory@heytings.org \
--cc=57499@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 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).