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





  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

  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=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 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).