GNU bug report logs - #64759
Broken faces

Previous Next

Full log

Message #38 received at 64759 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 64759 <at> debbugs.gnu.org, maurooaranda <at> gmail.com
Subject: Re: bug#64759: Broken faces
Date: Fri, 21 Jul 2023 19:39:33 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 64759 <at> debbugs.gnu.org,  maurooaranda <at> gmail.com
> Date: Fri, 21 Jul 2023 19:20:44 +0300
> 
> >> It seems adding non-empty definitions in bug#64655
> >> were intended to workaround a bug in cus-edit.el,
> >> not to fix it.
> >
> > I don't think it's a bug.  Why is it a bug to tell the user that the
> > face has no information to show as the current definition?
> 
> How this is different from a variable that has a nil value?
> The Customization UI can handle it.

It can and it does.  Emacs doesn't signal an error and doesn't crash.
So there's no problem, just unexpected info.

> > Moreover, what does it mean to have nil there in defface?  The
> > meaning of nil is not documented anywhere that I could see, so what
> > did the authors of such code expect it to produce?
> 
> Why not nil?  Every variable supports a nil value.  Why can't faces
> do the same?

I don't know, but the documentation says nothing about the semantics
of that.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.