bug#64759: Broken faces

bug#64759: Broken faces

[Juri Linkov]

This change broke display of `display-time-date-and-time' on the tab-bar:

  diff --git a/lisp/time.el b/lisp/time.el
  index 522bec46ac6..0184f96fcc2 100644
  --- a/lisp/time.el
  +++ b/lisp/time.el
  @@ -141,6 +141,7 @@ display-time-mail-face
   (defface display-time-date-and-time nil
     "Face for `display-time-format'."
  +  '((t (:inherit mode-line)))
     :group 'mode-line-faces
     :version "30.1")

This face is used by `tab-bar-format-global' that has nothing to do
with the mode line, so inheriting from `mode-line' makes no sense.

bug#64759: Broken faces

[Robert Pluim]

>>>>> On Fri, 21 Jul 2023 09:37:30 +0300, Juri Linkov <juri@linkov.net> said:

    Juri> This change broke display of `display-time-date-and-time' on the tab-bar:
    Juri>   diff --git a/lisp/time.el b/lisp/time.el
    Juri>   index 522bec46ac6..0184f96fcc2 100644
    Juri>   --- a/lisp/time.el
    Juri>   +++ b/lisp/time.el
    Juri>   @@ -141,6 +141,7 @@ display-time-mail-face
    Juri>    (defface display-time-date-and-time nil
    Juri>      "Face for `display-time-format'."
    Juri>   +  '((t (:inherit mode-line)))
    Juri>      :group 'mode-line-faces
    Juri>      :version "30.1")

Thatʼs from before 5513f72d3c8, no?

    Juri> This face is used by `tab-bar-format-global' that has nothing to do
    Juri> with the mode line, so inheriting from `mode-line' makes no sense.

Surely other items in the mode-line use the `mode-line' face already,
why is this one different?

Robert
-- 

bug#64759: Broken faces

[Juri Linkov]

>> This change broke display of `display-time-date-and-time' on the tab-bar:
>>   diff --git a/lisp/time.el b/lisp/time.el
>>   index 522bec46ac6..0184f96fcc2 100644
>>   --- a/lisp/time.el
>>   +++ b/lisp/time.el
>>   @@ -141,6 +141,7 @@ display-time-mail-face
>>    (defface display-time-date-and-time nil
>>      "Face for `display-time-format'."
>>   +  '((t (:inherit mode-line)))
>>      :group 'mode-line-faces
>>      :version "30.1")
>
> Thatʼs from before 5513f72d3c8, no?

5513f72d3c8 fixed a breakage, but the problem still remains.

>> This face is used by `tab-bar-format-global' that has nothing to do
>> with the mode line, so inheriting from `mode-line' makes no sense.
>
> Surely other items in the mode-line use the `mode-line' face already,
> why is this one different?

Because it's used on the tab bar.

bug#64759: Broken faces

[Eli Zaretskii]

> Cc: 64759@debbugs.gnu.org
> From: Juri Linkov <juri@linkov.net>
> Date: Fri, 21 Jul 2023 11:13:52 +0300
> 
> Because it's used on the tab bar.

Then perhaps tab-bar.el should define its own face for that, and apply
it when displaying time there.

bug#64759: Broken faces

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Fri, 21 Jul 2023 09:37:30 +0300
> 
> This change broke display of `display-time-date-and-time' on the tab-bar:
> 
>   diff --git a/lisp/time.el b/lisp/time.el
>   index 522bec46ac6..0184f96fcc2 100644
>   --- a/lisp/time.el
>   +++ b/lisp/time.el
>   @@ -141,6 +141,7 @@ display-time-mail-face
>    (defface display-time-date-and-time nil
>      "Face for `display-time-format'."
>   +  '((t (:inherit mode-line)))
>      :group 'mode-line-faces
>      :version "30.1")
> 
> This face is used by `tab-bar-format-global' that has nothing to do
> with the mode line, so inheriting from `mode-line' makes no sense.

??? It is AFAIU used whenever display-time-mode shows the time when
display-time-day-and-date is non-nil.  Where this is shown doesn't
matter, and by default this is shown on the mode line.  Thus "makes no
sense" sounds somewhat harsh to me.

But feel free to change the face definition as you see fit.

bug#64759: Broken faces

[Juri Linkov]

>> This change broke display of `display-time-date-and-time' on the tab-bar:
>>
>>   diff --git a/lisp/time.el b/lisp/time.el
>>   index 522bec46ac6..0184f96fcc2 100644
>>   --- a/lisp/time.el
>>   +++ b/lisp/time.el
>>   @@ -141,6 +141,7 @@ display-time-mail-face
>>    (defface display-time-date-and-time nil
>>      "Face for `display-time-format'."
>>   +  '((t (:inherit mode-line)))
>>      :group 'mode-line-faces
>>      :version "30.1")
>>
>> This face is used by `tab-bar-format-global' that has nothing to do
>> with the mode line, so inheriting from `mode-line' makes no sense.
>
> ??? It is AFAIU used whenever display-time-mode shows the time when
> display-time-day-and-date is non-nil.  Where this is shown doesn't
> matter, and by default this is shown on the mode line.  Thus "makes no
> sense" sounds somewhat harsh to me.

Sorry, I agree it makes sense when shown on the mode line.

> But feel free to change the face definition as you see fit.

It seems adding non-empty definitions in bug#64655
were intended to workaround a bug in cus-edit.el,
not to fix it.

Maybe Mauro could help to fix it (Cc'ed)
without requiring non-nil definitions
that anyway can not be fixed outside of
the Emacs source tree, i.e. in numerous
user init files and external packages.

bug#64759: Broken faces

[Mauro Aranda]

Juri Linkov <juri@linkov.net> writes:

 > It seems adding non-empty definitions in bug#64655
 > were intended to workaround a bug in cus-edit.el,
 > not to fix it.
 >
 > Maybe Mauro could help to fix it (Cc'ed)
 > without requiring non-nil definitions
 > that anyway can not be fixed outside of
 > the Emacs source tree, i.e. in numerous
 > user init files and external packages.

I don't think it is a bug in Custom.  Custom will allow the user to edit
the face and set/save or whatever, even if it's definition is
(defface foo nil "...")

But it seems to me that it's better to define it like this:
(defface foo '((t nil)) "...")
so that the face gets a face-defface-spec property.

So maybe the definition for display-time-date-and-time should be changed
to:
(defface display-time-date-and-time
   '((t nil))
   "Face for `display-time-format'."
   :group 'mode-line-faces
   :version "30.1")

instead that making it inherit from mode-line?

bug#64759: Broken faces

[Juri Linkov]

> But it seems to me that it's better to define it like this:
> (defface foo '((t nil)) "...")
> so that the face gets a face-defface-spec property.
>
> So maybe the definition for display-time-date-and-time should be changed
> to:
> (defface display-time-date-and-time
>   '((t nil))
>   "Face for `display-time-format'."
>   :group 'mode-line-faces
>   :version "30.1")
>
> instead that making it inherit from mode-line?

Thanks, I confirm that '((t nil)) solves this problem.
If a nil value can't be supported for faces, then
let's use '((t nil)).

bug#64759: Broken faces

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 64759@debbugs.gnu.org,  Eli Zaretskii <eliz@gnu.org>
> Date: Fri, 21 Jul 2023 19:21:40 +0300
> 
> Thanks, I confirm that '((t nil)) solves this problem.
> If a nil value can't be supported for faces, then
> let's use '((t nil)).

What do you expect this to produce for the face attributes?

bug#64759: Broken faces

[Juri Linkov]

>> Thanks, I confirm that '((t nil)) solves this problem.
>> If a nil value can't be supported for faces, then
>> let's use '((t nil)).
>
> What do you expect this to produce for the face attributes?

Let's see: when the definition is

  (defface display-time-date-and-time
    nil
    "Face for `display-time-format'."
    :group 'mode-line-faces
    :version "30.1")

then the customization buffer is

  Hide display-time-date-and-time face: [sample]
      State : NO CUSTOMIZATION DATA; not intended to be customized.
     Face for ‘display-time-format’.
     -- Empty face --
     Show All Attributes

But when the definition is

  (defface display-time-date-and-time
    '((t nil))
    "Face for `display-time-format'."
    :group 'mode-line-faces
    :version "30.1")

the customization buffer is

  Hide display-time-date-and-time face: [sample]
      State : STANDARD.
     Face for ‘display-time-format’.
     -- Empty face --
     Show All Attributes

Looks nice.  No strange error message about not intended to be customized.

bug#64759: Broken faces

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: maurooaranda@gmail.com,  64759@debbugs.gnu.org
> Date: Fri, 21 Jul 2023 20:51:57 +0300
> 
> >> Thanks, I confirm that '((t nil)) solves this problem.
> >> If a nil value can't be supported for faces, then
> >> let's use '((t nil)).
> >
> > What do you expect this to produce for the face attributes?
> 
> Let's see: when the definition is
> 
>   (defface display-time-date-and-time
>     nil
>     "Face for `display-time-format'."
>     :group 'mode-line-faces
>     :version "30.1")
> 
> then the customization buffer is
> 
>   Hide display-time-date-and-time face: [sample]
>       State : NO CUSTOMIZATION DATA; not intended to be customized.
>      Face for ‘display-time-format’.
>      -- Empty face --
>      Show All Attributes
> 
> But when the definition is
> 
>   (defface display-time-date-and-time
>     '((t nil))
>     "Face for `display-time-format'."
>     :group 'mode-line-faces
>     :version "30.1")
> 
> the customization buffer is
> 
>   Hide display-time-date-and-time face: [sample]
>       State : STANDARD.
>      Face for ‘display-time-format’.
>      -- Empty face --
>      Show All Attributes
> 
> Looks nice.  No strange error message about not intended to be customized.

That's not what I asked.  I asked about the face attributes.

IOW, isn't

  (defface display-time-date-and-time
    '((t nil))
    "Face for `display-time-format'."
    :group 'mode-line-faces
    :version "30.1")

the same as

  (defface display-time-date-and-time
    '((t (:inherit default)))
    "Face for `display-time-format'."
    :group 'mode-line-faces
    :version "30.1")

?

bug#64759: Broken faces

[Juri Linkov]

>> Let's see: when the definition is
>>
>>   (defface display-time-date-and-time
>>     nil
>>     "Face for `display-time-format'."
>>     :group 'mode-line-faces
>>     :version "30.1")
>>
>> then the customization buffer is
>>
>>   Hide display-time-date-and-time face: [sample]
>>       State : NO CUSTOMIZATION DATA; not intended to be customized.
>>      Face for ‘display-time-format’.
>>      -- Empty face --
>>      Show All Attributes
>>
>> But when the definition is
>>
>>   (defface display-time-date-and-time
>>     '((t nil))
>>     "Face for `display-time-format'."
>>     :group 'mode-line-faces
>>     :version "30.1")
>>
>> the customization buffer is
>>
>>   Hide display-time-date-and-time face: [sample]
>>       State : STANDARD.
>>      Face for ‘display-time-format’.
>>      -- Empty face --
>>      Show All Attributes
>>
>> Looks nice.  No strange error message about not intended to be customized.
>
> That's not what I asked.  I asked about the face attributes.
>
> IOW, isn't
>
>   (defface display-time-date-and-time
>     '((t nil))
>     "Face for `display-time-format'."
>     :group 'mode-line-faces
>     :version "30.1")
>
> the same as
>
>   (defface display-time-date-and-time
>     '((t (:inherit default)))
>     "Face for `display-time-format'."
>     :group 'mode-line-faces
>     :version "30.1")
>
> ?

No, it's not the same.  The latter uses a white background on the mode line.

bug#64759: Broken faces

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: maurooaranda@gmail.com,  64759@debbugs.gnu.org
> Date: Fri, 21 Jul 2023 21:49:13 +0300
> 
> No, it's not the same.  The latter uses a white background on the mode line.

So I ask again: what is the semantics of nil in this case?  We cannot
have in Emacs something that triggers undefined behavior, let alone
use it in our own sources.  The semantics of this must be known and
documented before we can use it.

bug#64759: Broken faces

[Juri Linkov]

>> No, it's not the same.  The latter uses a white background on the mode line.
>
> So I ask again: what is the semantics of nil in this case?  We cannot
> have in Emacs something that triggers undefined behavior, let alone
> use it in our own sources.  The semantics of this must be known and
> documented before we can use it.

The semantics of nil could be the same as '((t nil)).

Do you agree that currently the value '((t nil))
should be used for faces without default face attributes?

bug#64759: Broken faces

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: maurooaranda@gmail.com,  64759@debbugs.gnu.org
> Date: Mon, 24 Jul 2023 20:35:17 +0300
> 
> >> No, it's not the same.  The latter uses a white background on the mode line.
> >
> > So I ask again: what is the semantics of nil in this case?  We cannot
> > have in Emacs something that triggers undefined behavior, let alone
> > use it in our own sources.  The semantics of this must be known and
> > documented before we can use it.
> 
> The semantics of nil could be the same as '((t nil)).

And what is the semantics of '((t nil)) ?  What attributes will the
face have when realized?

> Do you agree that currently the value '((t nil))
> should be used for faces without default face attributes?

Yes, I think so.  If no better face to inherit from is available in
each such case, that is.

bug#64759: Broken faces

[Juri Linkov]

>> The semantics of nil could be the same as '((t nil)).
>
> And what is the semantics of '((t nil)) ?  What attributes will the
> face have when realized?

No attributes.  This is the standard value used by empty faces.

>> Do you agree that currently the value '((t nil))
>> should be used for faces without default face attributes?
>
> Yes, I think so.  If no better face to inherit from is available in
> each such case, that is.

This means these faces should have by default '((t nil)):
semantic-decoration-on-includes, shr-h4, shr-h5, shr-h6,
nxml-text, nxml-delimiter, nxml-element-colon, makefile-shell
as before?

bug#64759: Broken faces

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: maurooaranda@gmail.com,  64759@debbugs.gnu.org
> Date: Tue, 25 Jul 2023 20:04:16 +0300
> 
> >> The semantics of nil could be the same as '((t nil)).
> >
> > And what is the semantics of '((t nil)) ?  What attributes will the
> > face have when realized?
> 
> No attributes.  This is the standard value used by empty faces.

What does this mean?  For example, what would be the foreground color?
what would be the font? etc.

I'm not familiar with "empty face" notion.  A face always has
attributes when it is fully realized, otherwise Emacs will be unable
to use it.

> >> Do you agree that currently the value '((t nil))
> >> should be used for faces without default face attributes?
> >
> > Yes, I think so.  If no better face to inherit from is available in
> > each such case, that is.
> 
> This means these faces should have by default '((t nil)):
> semantic-decoration-on-includes, shr-h4, shr-h5, shr-h6,
> nxml-text, nxml-delimiter, nxml-element-colon, makefile-shell
> as before?

Only if "no better face to inherit from is available" in all of those
cases.  Which I'm not sure is true.  If you are sure, please tell why
the faces I put there are not better ideas.

bug#64759: Broken faces

[Juri Linkov]

>> >> The semantics of nil could be the same as '((t nil)).
>> >
>> > And what is the semantics of '((t nil)) ?  What attributes will the
>> > face have when realized?
>>
>> No attributes.  This is the standard value used by empty faces.
>
> What does this mean?  For example, what would be the foreground color?
> what would be the font? etc.

No foreground color, and no font.

> I'm not familiar with "empty face" notion.  A face always has
> attributes when it is fully realized, otherwise Emacs will be unable
> to use it.

"Empty face" is the standard notion.  Here's an example how it's used:

1. M-x make-empty-face RET foo RET
2. M-x customize-face RET foo RET

Then output is:

  Hide Foo face: [sample]
      State : NO CUSTOMIZATION DATA; not intended to be customized.
     nil
     -- Empty face --

>> >> Do you agree that currently the value '((t nil))
>> >> should be used for faces without default face attributes?
>> >
>> > Yes, I think so.  If no better face to inherit from is available in
>> > each such case, that is.
>>
>> This means these faces should have by default '((t nil)):
>> semantic-decoration-on-includes, shr-h4, shr-h5, shr-h6,
>> nxml-text, nxml-delimiter, nxml-element-colon, makefile-shell
>> as before?
>
> Only if "no better face to inherit from is available" in all of those
> cases.  Which I'm not sure is true.  If you are sure, please tell why
> the faces I put there are not better ideas.

Because they will cause the same problem as with display-time-date-and-time,
except that other faces are used less often, so it will take time until users
will notice these problems.

bug#64759: Broken faces

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: maurooaranda@gmail.com,  64759@debbugs.gnu.org
> Date: Fri, 28 Jul 2023 20:30:44 +0300
> 
> >> >> The semantics of nil could be the same as '((t nil)).
> >> >
> >> > And what is the semantics of '((t nil)) ?  What attributes will the
> >> > face have when realized?
> >>
> >> No attributes.  This is the standard value used by empty faces.
> >
> > What does this mean?  For example, what would be the foreground color?
> > what would be the font? etc.
> 
> No foreground color, and no font.

There can be no such face.

> > I'm not familiar with "empty face" notion.  A face always has
> > attributes when it is fully realized, otherwise Emacs will be unable
> > to use it.
> 
> "Empty face" is the standard notion.  Here's an example how it's used:
> 
> 1. M-x make-empty-face RET foo RET
> 2. M-x customize-face RET foo RET
> 
> Then output is:
> 
>   Hide Foo face: [sample]
>       State : NO CUSTOMIZATION DATA; not intended to be customized.
>      nil
>      -- Empty face --

We are mis-communicating.  My point is that we need to explain in the
documentation the effect of such a defface when the face is realized
and displayed.  Lisp programmers need to understand that to be able to
use this correctly and predictably.

> > Only if "no better face to inherit from is available" in all of those
> > cases.  Which I'm not sure is true.  If you are sure, please tell why
> > the faces I put there are not better ideas.
> 
> Because they will cause the same problem as with display-time-date-and-time,
> except that other faces are used less often, so it will take time until users
> will notice these problems.

display-time-date-and-time is used on the mode line, where the colors
are different.  The other faces are for buffer text, so the problems
with display-time-date-and-time don't necessarily apply.

bug#64759: Broken faces

[Juri Linkov]

>> 1. M-x make-empty-face RET foo RET
>> 2. M-x customize-face RET foo RET
>> 
>> Then output is:
>> 
>>   Hide Foo face: [sample]
>>       State : NO CUSTOMIZATION DATA; not intended to be customized.

Please note that the problem is still unfixed for
"NO CUSTOMIZATION DATA".

>>      nil
>>      -- Empty face --
>
> We are mis-communicating.  My point is that we need to explain in the
> documentation the effect of such a defface when the face is realized
> and displayed.  Lisp programmers need to understand that to be able to
> use this correctly and predictably.

For example, in *scratch* eval:

  (put-text-property (point-min) (point-max)
                     'font-lock-face (make-empty-face 'foo))

Then 'C-u C-x =' shows:

  There are text properties here:
    font-lock-face       foo

Then clicking on 'foo' shows:

  Face: foo (sample) (customize this face)
  Documentation:
  Not documented as a face.
             Family: unspecified
            Foundry: unspecified
              Width: unspecified
             Height: unspecified
             Weight: unspecified
              Slant: unspecified
         Foreground: unspecified
  DistantForeground: unspecified
         Background: unspecified
          Underline: unspecified
           Overline: unspecified
     Strike-through: unspecified
                Box: unspecified
            Inverse: unspecified
            Stipple: unspecified
               Font: unspecified
            Fontset: unspecified
             Extend: unspecified
            Inherit: unspecified

That's all that Lisp programmers need to know: that in an empty face
all attributes are unspecified.

>> > Only if "no better face to inherit from is available" in all of those
>> > cases.  Which I'm not sure is true.  If you are sure, please tell why
>> > the faces I put there are not better ideas.
>> 
>> Because they will cause the same problem as with display-time-date-and-time,
>> except that other faces are used less often, so it will take time until users
>> will notice these problems.
>
> display-time-date-and-time is used on the mode line, where the colors
> are different.  The other faces are for buffer text, so the problems
> with display-time-date-and-time don't necessarily apply.

It's possible that these faces are applied over other faces
that will break the default theme.

bug#64759: Broken faces

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: maurooaranda@gmail.com,  64759@debbugs.gnu.org
> Date: Mon, 31 Jul 2023 20:42:22 +0300
> 
> Then clicking on 'foo' shows:
> 
>   Face: foo (sample) (customize this face)
>   Documentation:
>   Not documented as a face.
>              Family: unspecified
>             Foundry: unspecified
>               Width: unspecified
>              Height: unspecified
>              Weight: unspecified
>               Slant: unspecified
>          Foreground: unspecified
>   DistantForeground: unspecified
>          Background: unspecified
>           Underline: unspecified
>            Overline: unspecified
>      Strike-through: unspecified
>                 Box: unspecified
>             Inverse: unspecified
>             Stipple: unspecified
>                Font: unspecified
>             Fontset: unspecified
>              Extend: unspecified
>             Inherit: unspecified
> 
> That's all that Lisp programmers need to know: that in an empty face
> all attributes are unspecified.

See, I don't think this is accurate.  I think the result depends on
the default attributes, the ones you can change by using
set-face-attribute with FRAME set to t.

> >> > Only if "no better face to inherit from is available" in all of those
> >> > cases.  Which I'm not sure is true.  If you are sure, please tell why
> >> > the faces I put there are not better ideas.
> >> 
> >> Because they will cause the same problem as with display-time-date-and-time,
> >> except that other faces are used less often, so it will take time until users
> >> will notice these problems.
> >
> > display-time-date-and-time is used on the mode line, where the colors
> > are different.  The other faces are for buffer text, so the problems
> > with display-time-date-and-time don't necessarily apply.
> 
> It's possible that these faces are applied over other faces
> that will break the default theme.

Such use of these faces only makes sense if the face is customized to
have some attributes different from the defaults.  The intention of
the default definition of these faces is to make them look no
different from the default face.

bug#64759: Broken faces

[Mauro Aranda]

Juri Linkov <juri@linkov.net> writes:

 >>> 1. M-x make-empty-face RET foo RET
 >>> 2. M-x customize-face RET foo RET
 >>>
 >>> Then output is:
 >>>
 >>>   Hide Foo face: [sample]
 >>>       State : NO CUSTOMIZATION DATA; not intended to be customized.
 >
 > Please note that the problem is still unfixed for
 > "NO CUSTOMIZATION DATA".
 >

I don't think this is a problem.  defface wasn't used here, so the face
might not be intended to be customized.

bug#64759: Broken faces

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 64759@debbugs.gnu.org,  Mauro Aranda <maurooaranda@gmail.com>
> Date: Fri, 21 Jul 2023 11:13:13 +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?

bug#64759: Broken faces

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 64759@debbugs.gnu.org,  Mauro Aranda <maurooaranda@gmail.com>
> Date: Fri, 21 Jul 2023 11:13:13 +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?

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?

bug#64759: Broken faces

[Juri Linkov]

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

> 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?

bug#64759: Broken faces

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 64759@debbugs.gnu.org,  maurooaranda@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.