From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Lars Ingebrigtsen <larsi@gnus.org>
Cc: "damien@cassou.me" <damien@cassou.me>,
"54156@debbugs.gnu.org" <54156@debbugs.gnu.org>
Subject: bug#54156: [External] : bug#54156: 28.0.91; set-face-attribute with a nil FRAME doesn't change the default
Date: Sat, 26 Feb 2022 16:17:19 +0000 [thread overview]
Message-ID: <SJ0PR10MB5488EBD93883124F4B128818F33F9@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <83h78lps6m.fsf@gnu.org>
> > > So we need a special trick to override defface with 'unspecified',
> > > and that trick is this call:
> > > (set-face-attribute 'region t :background 'unspecified)
> > > This is handled specially in internal-set-lisp-face-attribute
> > > to do what Damien wants.
> >
> > So perhaps set-face-attribute should do that automatically when
> > handed a nil value?
>
> The fact that we handle nil as 'unspecified' in the case of the color
> is for compatibility with Emacs 20. In Emacs 21 and later, a color
> cannot be nil. This is well-documented: a color must be a string or
> 'unspecified'. I don't think we want to resurrect that old convention
> of nil; it's just that Damien and others will have to get used to not
> using nil for a color.
What Eli says here makes sense to me. We could also
perhaps explicitly (more visibly) recommend that you
always use an explicit `unspecified' rather than nil.
___
It does not make sense to me to change the longstanding
behavior, to make `set-face-attibute' do something
different (and backward-incompatible). As Eli said:
"This is basic in how faces are handled in Emacs; we
cannot easily change that without breaking gobs of code."
___
I'm not sure I understand this from Eli, however:
The correct way to do what Damien wants (AFAIU) is this:
(set-face-attribute 'region nil :background 'unspecified)
(set-face-attribute 'region t :background 'unspecified)
That is, one must explicitly call set-face-attribute
with FRAME = t (as well as nil), and pass 'unspecified'
^^^^^^^^^^^^^^^^^^
(NOT nil!) as the value. Maybe we should document that,
although it is a obscure and unusual thing to do.
My impression is that it's enough to do this:
(set-face-attribute 'region nil :background 'unspecified)
I'm probably not testing/checking this correctly,
but it seems to me that both the selected frame
and new (future) frames are affected by using
nil for the frame (and `unspecified' for the
face attribute value).
In any case, yes, whatever the correct message
is for users, please do consider adding it to
the doc. You might consider this an unusual
thing to do (why so?), but misunderstanding this
is a gotcha that we should help users avoid.
Eli, you say "This is well-documented: a color
must be a string or 'unspecified'." Still, it
wouldn't hurt to add something to that effect in
the doc of `set-face-attribute' - and say what
the effect is of using nil (for the face color)
- it's tolerated (no error) but it doesn't have
the effect of `unspecified'.
next prev parent reply other threads:[~2022-02-26 16:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 10:21 bug#54156: 28.0.91; set-face-attribute with a nil FRAME doesn't change the default Damien Cassou
2022-02-25 12:15 ` Lars Ingebrigtsen
2022-02-25 12:26 ` Eli Zaretskii
2022-02-25 12:30 ` Lars Ingebrigtsen
2022-02-25 13:03 ` Eli Zaretskii
2022-02-25 13:12 ` Lars Ingebrigtsen
2022-02-25 13:24 ` Eli Zaretskii
2022-02-25 15:42 ` bug#54156: [External] : " Drew Adams
2022-02-26 15:04 ` Lars Ingebrigtsen
2022-02-26 15:24 ` Eli Zaretskii
2022-02-26 16:17 ` Drew Adams [this message]
2022-02-26 16:35 ` bug#54156: [External] : " Eli Zaretskii
2022-02-26 17:23 ` Drew Adams
2022-02-26 17:50 ` Eli Zaretskii
2022-02-26 22:47 ` Drew Adams
2022-02-27 7:04 ` Eli Zaretskii
2022-02-27 15:49 ` Drew Adams
2022-02-27 13:02 ` Lars Ingebrigtsen
2022-02-27 16:13 ` bug#54156: [External] : " Drew Adams
2022-02-25 12:16 ` 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=SJ0PR10MB5488EBD93883124F4B128818F33F9@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=54156@debbugs.gnu.org \
--cc=damien@cassou.me \
--cc=eliz@gnu.org \
--cc=larsi@gnus.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.