all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Felix Dietrich <felix.dietrich@sperrhaken.name>
To: Robert Pluim <rpluim@gmail.com>
Cc: help-gnu-emacs@gnu.org
Subject: Re: how to track down "invalid face attribute" errors?
Date: Wed, 05 Oct 2022 14:32:04 +0200	[thread overview]
Message-ID: <87a66acuyj.fsf@sperrhaken.name> (raw)
In-Reply-To: 87ill89ag4.fsf@gmail.com

Hello Robert,

Emanuel Berg <incal@dataswamp.org> writes:
>
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> some package I'm using is leading to errors of the form
>> 
>>   Invalid face attribute :foreground nil [54 times]
>> 
>> can anybody suggest how I can track down which package/function is
>> causing this?  Debugging on error doesn't catch this.
>
> Sounds like that error message should be changed to include
> what face causes trouble, if possible?


Robert Pluim <rpluim@gmail.com> writes:
>
> Felix Dietrich <felix.dietrich@sperrhaken.name> writes:
>
>> Robert Pluim <rpluim@gmail.com> writes:
>>>
>>> (If you have a reproducer, we can look at changing the message)
>>
>> Here is one:
>>
>> #+begin_src emacs-lisp
>>   (let ((buf (generate-new-buffer "*test*"))
>>         (s (propertize "Hello World" 'face '(:foreground nil))))
>>     (with-current-buffer buf
>>       (insert s))
>>     (display-buffer buf))
>> #+end_src
>
> Thereʼs no actual face there for Emacs to log, what the low-level code
> receives is "(:foreground nil)"

But “xfaces.c:merge_face_ref” (which produces the error message) has a
“struct window w” parameter.  I believe in cases where it is not NULL,
which it isnʼt when running the above code, this could be used to derive
the buffer and the bufferʼs position using the struct members “contents”
and “pointm’: 1. “contents” stores, for leaf windows, the windows
buffer; its descriptions mentions other possible value types it may hold
[1]; I do not know in how far these other types have to be considered
here.  2. “pointm” refers to a marker holding the current buffer
position in window; its description states that it is “used only when
the window is not selected”.  Therefore, it is possible that, if the
window “w” is the selected one, the point would have to be taken from
another source (perhaps the “PT” macro in “buffer.h”).

Also note that, if the position would be added to the log entry,
multiple log entries would not be merged anymore.  Additionally, with
the code above, the position is actually after the text (at
‘point-max’); therefore, this might not be useful information to add.

I am not sure if the whole thing is worth the effort or would complicate
the creation of a simple log entry for a, hopefully, rare case to much.

Anyway, perhaps, if there is any interest in adding information to the
“Invalid face attribute” log message, further discussion should move to
a wishlist bug report?


Robert Pluim <rpluim@gmail.com> writes:
>
> Felix Dietrich <felix.dietrich@sperrhaken.name> writes
>>
>> Upon evaluation, the resulting output in the “*Messages*” buffer also
>> shows another issues with a missing newline between messages (in Emacs
>> 28.1 at least).
>
>> #+begin_example
>> #<window 54 on *test*<2>>Invalid face attribute :foreground nil
>> Invalid face attribute :foreground nil
>> #+end_example
>
> Itʼs still there in emacs-29, but itʼs deep in the guts of the elisp
> engine, so I havenʼt found exactly where it comes from.

If there isnʼt one already, I try to remember to file a minor bug report
sometime in the next couple of days.


>> Maybe a value of nil for the :foreground attribute in an anonymous face
>> should be handled the same way as it is in a face defined with
>> ‘defface’, that is being treated as the symbol ‘unspecified’?
>
>> #+begin_src emacs-lisp
>>   (progn
>>     (defface my/test '((t . (:foreground nil))) "test face")
>>     (face-attribute 'my/test :foreground))
>> #+end_src
>
>> #+RESULTS:
>> : unspecified
>
> There was recently a long thread about this on emacs-devel, which I
> didnʼt read :-) It might be worth suggesting this there.

I donʼt seem to be able to find it.


Footnotes:
[1]  “For a leaf window or a tooltip window this is the buffer shown
      in the window; for a combination window this is the first of
      its child windows; for a pseudo window showing the menu bar or
      tool bar this is nil.  It is a buffer for a minibuffer window
      as well.”
      — Description of the “contents” member of “struct window”
        copied from the file “window.h”

-- 
Felix Dietrich



  reply	other threads:[~2022-10-05 12:32 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 [this message]
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
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=87a66acuyj.fsf@sperrhaken.name \
    --to=felix.dietrich@sperrhaken.name \
    --cc=help-gnu-emacs@gnu.org \
    --cc=rpluim@gmail.com \
    /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.