all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Felix Dietrich <felix.dietrich@sperrhaken.name>
To: help-gnu-emacs@gnu.org
Subject: Re: how to track down "invalid face attribute" errors?
Date: Mon, 03 Oct 2022 21:19:41 +0200	[thread overview]
Message-ID: <87wn9g4svm.fsf@sperrhaken.name> (raw)
In-Reply-To: <87r0zudtve.fsf@dataswamp.org> (Emanuel Berg's message of "Thu, 29 Sep 2022 18:32:05 +0200")

[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]

Hello Emanuel,

Emanuel Berg <incal@dataswamp.org> writes:

> Stefan Monnier via Users list for the GNU Emacs text editor wrote:
>
>>> Sounds like that error message should be changed to include
>>> what face causes trouble, if possible?
>>
>> IIUC this message comes when the face is not a symbol but
>> a plist of properties, so there's a good chance that
>> printing the face will just say (:foreground nil) and thus
>> won't help you. [...]
>
> Okay, but why are the face used before they even have a name?

Those are *anonymous* faces.  You can attach these to text or overlay
properties.  If I recall correctly, the Emacs Lisp manual recommends
using named faces but recognises that anonymous faces might have some
uses.

> Isn't it better to initialize the faces first, and if it is
> attempted to define them using invalid attributes, then that
> would be an error?

This already happens to a degree for named faces: if you use ‘defface’
to create a face with :foreground set to nil, subsequent calls to
‘face-attribute’ for :foreground on that face will return ‘unspecified’:

#+begin_src emacs-lisp
  (progn
    (defface my/test '((t . (:foreground nil))) "test face")
    (face-attribute 'my/test :foreground))
#+end_src

#+RESULTS:
: unspecified


If I skimmed the code correctly, this is done in
“xfaces.c:internal-set-lisp-face-attribute” around line 3344 (note that
there is also a check to ensure that the :foreground attribute is a
string):

#+NAME: xfaces.c:3344
#+begin_src c
  else if (EQ (attr, QCforeground))
    {
      /* Compatibility with 20.x.  */
      if (NILP (value))
        value = Qunspecified;
      if (!UNSPECIFIEDP (value) && !IGNORE_DEFFACE_P (value))
        {
          /* Don't check for valid color names here because it depends
             on the frame (display) whether the color will be valid
             when the face is realized.  */
          CHECK_STRING (value);
          if (SCHARS (value) == 0)
            signal_error ("Empty foreground color value", value);
        }
#+end_src


In “xfaces.c:merge_face_ref”, around line 2728, on the other hand,
everything but strings is considered an error for the :foreground
attribute:

#+NAME: xfaces.c:2728
#+begin_src c
              else if (EQ (keyword, QCforeground))
                {
                  if (STRINGP (value))
                    to[LFACE_FOREGROUND_INDEX] = value;
                  else
                    err = true;
                }
#+end_src c

Maybe just a missing check to allow NILP for the :foreground value in
“xfaces.c:2728” (completely untested):


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Patch to also allow NILP for :foreground in merge_face_ref --]
[-- Type: text/x-patch, Size: 428 bytes --]

diff --git a/src/xfaces.c b/src/xfaces.c
index f7ee19195f..ab624a8d87 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -2727,7 +2727,9 @@ merge_face_ref (struct window *w,
 		}
 	      else if (EQ (keyword, QCforeground))
 		{
-		  if (STRINGP (value))
+		  if (NILP (value))
+		    to[LFACE_FOREGROUND_INDEX] = Qunspecified;
+		  else if (STRINGP (value))
 		    to[LFACE_FOREGROUND_INDEX] = value;
 		  else
 		    err = true;

[-- Attachment #3: Type: text/plain, Size: 20 bytes --]


-- 
Felix Dietrich

  reply	other threads:[~2022-10-03 19:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-25 12:03 how to track down "invalid face attribute" errors? Eric S Fraga
2022-09-25 13:00 ` Emanuel Berg
2022-09-26  9:04   ` Eric S Fraga
2022-09-26  9:40     ` Robert Pluim
2022-09-26  9:50       ` Fraga, Eric
2022-09-27 11:12       ` Felix Dietrich
2022-09-27 14:08         ` Robert Pluim
2022-10-05 12:32           ` Felix Dietrich
2022-10-05 13:31             ` Robert Pluim
2022-10-05 13:51             ` Eli Zaretskii
2022-10-06 14:58               ` Felix Dietrich
2022-09-28 11:41   ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-09-28 15:04     ` Robert Pluim
2022-09-29 16:32     ` Emanuel Berg
2022-10-03 19:19       ` Felix Dietrich [this message]
2022-10-03 22:46         ` Emanuel Berg
2022-10-04 11:06         ` Felix Dietrich
2022-10-05 11:29           ` Felix Dietrich
2022-09-25 14:01 ` Eli Zaretskii
2022-09-25 15:53   ` Eric S Fraga
2022-09-25 16:06     ` Eli Zaretskii
2022-09-25 17:20       ` Eric S Fraga
2022-09-25 14:26 ` Felix Dietrich
2022-09-25 15:51   ` Fraga, Eric

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wn9g4svm.fsf@sperrhaken.name \
    --to=felix.dietrich@sperrhaken.name \
    --cc=help-gnu-emacs@gnu.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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.