all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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: Thu, 01 Sep 2022 08:25:35 +0000	[thread overview]
Message-ID: <f61b9c2619aab1ad9813@heytings.org> (raw)
In-Reply-To: <837d2nshh7.fsf@gnu.org>


>> I just want to make it as clear as possible that to get that special 
>> value `unspecified' one should use the symbol 'unspecified.
>
> We have gazillions of such situations everywhere in Emacs where symbol 
> values are documented, and we never say anything beyond the name of the 
> symbol with proper quoting.
>

For some reason this situation seems different (from a user point of 
view), give that the same question pops again and again.  Why is adding 
such a note a problem?

>
> That is why the doc string mentions 'defface', and that's why it talks 
> specifically about new frames.  I thought mentioning both makes the 
> extra set-face-attribute call with FRAME = t natural and easier to 
> remember and apply.
>

I'm really puzzled.  Why should the value 'unspecified be mentioned there 
as if it were somehow different from the other possible values, when in 
fact it isn't?  Once again when one calls

(set-face-attribute 'isearch nil :background 'unspecified)

this is what is happening:

(internal-set-lisp-face-attributes 'isearch :background 'unspecified 0)

which calls, recursively:

(internal-set-lisp-face-attributes 'isearch :background 'unspecified t)
(internal-set-lisp-face-attributes 'isearch :background 'unspecified #<frame-1>)
...
(internal-set-lisp-face-attributes 'isearch :background 'unspecified #<frame-n>)

And when one calls

(set-face-attribute 'isearch t :background 'unspecified)

this is what is happening:

(internal-set-lisp-face-attributes 'isearch :background 'unspecified t)

So this call is already included in the previous one.  Why should we tell 
users to add such a redundant call in their code?

As far as I understand, the actual and real problem here is some users use 
nil when they should use 'unspecified, because they are not aware that nil 
and 'unspecified are subtly different.  The subtle difference is that 
using nil works for frame = #<frame-1> ... #<frame-n>, but does not work 
with frame = t.

>
> In addition to the attribute values listed below, all attributes can 
> also be set to the special value `unspecified', which means the face 
> doesn't by itself specify a value for the attribute.
>

With "... the special value `unspecified' (for which the explicit symbol 
'unspecified must be used), which means ...", that'd be okay.

>
> When a new frame is created, attribute values in the FACE's `defspec' 
> normally override the `unspecified' values in the FACE's default 
> attributes.  To avoid that, i.e. to cause ATTRIBUTE's value be reset to 
> `unspecified' when creating new frames, disregarding what the FACE's 
> face spec says, call this function with FRAME set to t and the 
> ATTRIBUTE's value set to `unspecified'.
>

See above: I really don't understand why the 'unspecified value should be 
detailed as if it were different from the other values, when in fact it 
isn't.  The real and actual problem here is that users are confused by the 
fact that a nil value for an attribute is equivalent to an 'unspecified 
value for existing frames, but is not equivalent to 'unspecified for new 
frames.





  reply	other threads:[~2022-09-01  8:25 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
2022-09-01  7:04                         ` Eli Zaretskii
2022-09-01  8:25                           ` Gregory Heytings [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f61b9c2619aab1ad9813@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 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.