GNU bug report logs - #64759
Broken faces

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64759 <at> debbugs.gnu.org, maurooaranda <at> gmail.com
Subject: bug#64759: Broken faces
Date: Mon, 31 Jul 2023 20:42:22 +0300

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

Previous Next

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