bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54156: [External] : bug#54156: 28.0.91; set-face-attribute with a ni


From: Drew Adams
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 17:23:22 +0000

> > 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).
> 
> I'm not sure this isn't the result of the particular implementation we
> have, so I prefer to tell people to call with FRAME = t explicitly.
> After all, this is a rare use case.

But is what I said correct, that just using nil
as the frame makes both the existing frames and
future ones use `unspecified' as the face value?

That's what I think I see, and that was what OP
was after, IIUC.

IOW, is it really necessary to use two calls to
`set-face-attribute', one with nil FRAME and one
with `t' FRAME?

And using _only_ `t' doesn't set the attribute
to `unspecified' for the existing frames, right?

> > 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'.
> 
> We generally don't advertise compatibility shims for obsolete
> features, because we want people to stop using them.

Is it declared to be obsolete?  We generally do
let users know when something they use is obsolete,
e.g. with a warning.  Do we do that for this case?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]