* how to track down "invalid face attribute" errors? @ 2022-09-25 12:03 Eric S Fraga 2022-09-25 13:00 ` Emanuel Berg ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Eric S Fraga @ 2022-09-25 12:03 UTC (permalink / raw) To: help-gnu-emacs Hello all, 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. All web searches lead me to specific packages that have had this error in the past (none of which I use). Thank you, eric -- Eric S Fraga via gnus (Emacs 29.0.50 2022-09-22) on Debian 11.4 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 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-28 11:41 ` Stefan Monnier via Users list for the GNU Emacs text editor 2022-09-25 14:01 ` Eli Zaretskii 2022-09-25 14:26 ` Felix Dietrich 2 siblings, 2 replies; 24+ messages in thread From: Emanuel Berg @ 2022-09-25 13:00 UTC (permalink / raw) To: help-gnu-emacs Eric S Fraga wrote: > 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. All web searches lead me to specific packages > that have had this error in the past (none of which I use). Sounds like that error message should be changed to include what face causes trouble, if possible? BTW here is a function to loop thru all faces and set them to something, try for example ;; (set-all-faces "red") Maybe you can modify that to retrieve attributes instead? That could be cool ... (defun set-all-faces (fg &optional bg weight) (let ((backg (or bg "black")) (wght (or weight 'normal)) (faces) ) (mapatoms (lambda (s) (when (facep s) (push (symbol-name s) faces) ))) (dolist (f faces) (set-face-attribute (intern f) nil :foreground fg) :background backg :weight wght :italic nil) )) -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 2022-09-25 13:00 ` Emanuel Berg @ 2022-09-26 9:04 ` Eric S Fraga 2022-09-26 9:40 ` Robert Pluim 2022-09-28 11:41 ` Stefan Monnier via Users list for the GNU Emacs text editor 1 sibling, 1 reply; 24+ messages in thread From: Eric S Fraga @ 2022-09-26 9:04 UTC (permalink / raw) To: help-gnu-emacs On Sunday, 25 Sep 2022 at 15:00, Emanuel Berg wrote: > Sounds like that error message should be changed to include > what face causes trouble, if possible? That sounds useful. -- Eric S Fraga via gnus (Emacs 29.0.50 2022-09-26) on Debian 11.5 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 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 0 siblings, 2 replies; 24+ messages in thread From: Robert Pluim @ 2022-09-26 9:40 UTC (permalink / raw) To: Eric S Fraga; +Cc: help-gnu-emacs >>>>> On Mon, 26 Sep 2022 10:04:09 +0100, Eric S Fraga <e.fraga@ucl.ac.uk> said: Eric> On Sunday, 25 Sep 2022 at 15:00, Emanuel Berg wrote: >> Sounds like that error message should be changed to include >> what face causes trouble, if possible? Eric> That sounds useful. I think youʼre looking for the `debug-on-message' variable, since this is a log in *Messages*, not an error. (If you have a reproducer, we can look at changing the message) Robert -- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 2022-09-26 9:40 ` Robert Pluim @ 2022-09-26 9:50 ` Fraga, Eric 2022-09-27 11:12 ` Felix Dietrich 1 sibling, 0 replies; 24+ messages in thread From: Fraga, Eric @ 2022-09-26 9:50 UTC (permalink / raw) To: Robert Pluim; +Cc: help-gnu-emacs@gnu.org On Monday, 26 Sep 2022 at 11:40, Robert Pluim wrote: > I think youʼre looking for the `debug-on-message' variable, since this > is a log in *Messages*, not an error. Excellent. Definitely what I was looking for (and knew about at some point in the past but forgot completely). -- Eric S Fraga via gnus (Emacs 29.0.50 2022-09-26) on Debian bullseye/sid ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 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 1 sibling, 1 reply; 24+ messages in thread From: Felix Dietrich @ 2022-09-27 11:12 UTC (permalink / raw) To: Robert Pluim; +Cc: Eric S Fraga, help-gnu-emacs Robert Pluim <rpluim@gmail.com> writes: > On Mon, 26 Sep 2022 10:04:09 +0100, Eric S Fraga <e.fraga@ucl.ac.uk> said: > >> On Sunday, 25 Sep 2022 at 15:00, Emanuel Berg wrote: >> >>> Sounds like that error message should be changed to include >>> what face causes trouble, if possible? > > I think youʼre looking for the `debug-on-message' variable, since this > is a log in *Messages*, not an error. Would this work in this case? The variable ‘debug-on-message’ seems to be handled in the C-function ‘set_message’ which, on a cursory glance, I cannot see being called from ‘add_to_log’ or below. Therefore, ‘debug-on-message’ may be bypassed in this case here. > (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 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 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 -- Felix Dietrich ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 2022-09-27 11:12 ` Felix Dietrich @ 2022-09-27 14:08 ` Robert Pluim 2022-10-05 12:32 ` Felix Dietrich 0 siblings, 1 reply; 24+ messages in thread From: Robert Pluim @ 2022-09-27 14:08 UTC (permalink / raw) To: Felix Dietrich; +Cc: Eric S Fraga, help-gnu-emacs >>>>> On Tue, 27 Sep 2022 13:12:12 +0200, Felix Dietrich <felix.dietrich@sperrhaken.name> said: Felix> Robert Pluim <rpluim@gmail.com> writes: >> On Mon, 26 Sep 2022 10:04:09 +0100, Eric S Fraga <e.fraga@ucl.ac.uk> said: >> >>> On Sunday, 25 Sep 2022 at 15:00, Emanuel Berg wrote: >>> >>>> Sounds like that error message should be changed to include >>>> what face causes trouble, if possible? >> >> I think youʼre looking for the `debug-on-message' variable, since this >> is a log in *Messages*, not an error. Felix> Would this work in this case? The variable ‘debug-on-message’ seems to Felix> be handled in the C-function ‘set_message’ which, on a cursory glance, I Felix> cannot see being called from ‘add_to_log’ or below. Therefore, Felix> ‘debug-on-message’ may be bypassed in this case here. In that case gdb and something like this gdb emacs > b add_to_log > commands > bt > c > end > run add_to_log is not called that often, so this shouldnʼt create too much output. >> (If you have a reproducer, we can look at changing the message) Felix> Here is one: Felix> #+begin_src emacs-lisp Felix> (let ((buf (generate-new-buffer "*test*")) Felix> (s (propertize "Hello World" 'face '(:foreground nil)))) Felix> (with-current-buffer buf Felix> (insert s)) Felix> (display-buffer buf)) Felix> #+end_src Thereʼs no actual face there for Emacs to log, what the low-level code receives is "(:foreground nil)" Felix> Upon evaluation, the resulting output in the “*Messages*” buffer also Felix> shows another issues with a missing newline between messages (in Emacs Felix> 28.1 at least). Felix> #+begin_example Felix> #<window 54 on *test*<2>>Invalid face attribute :foreground nil Felix> Invalid face attribute :foreground nil Felix> #+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. Felix> Maybe a value of nil for the :foreground attribute in an anonymous face Felix> should be handled the same way as it is in a face defined with Felix> ‘defface’, that is being treated as the symbol ‘unspecified’? Felix> #+begin_src emacs-lisp Felix> (progn Felix> (defface my/test '((t . (:foreground nil))) "test face") Felix> (face-attribute 'my/test :foreground)) Felix> #+end_src Felix> #+RESULTS: Felix> : unspecified There was recently a long thread about this on emacs-devel, which I didnʼt read :-) It might be worth suggesting this there. Robert -- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 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 0 siblings, 2 replies; 24+ messages in thread From: Felix Dietrich @ 2022-10-05 12:32 UTC (permalink / raw) To: Robert Pluim; +Cc: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 2022-10-05 12:32 ` Felix Dietrich @ 2022-10-05 13:31 ` Robert Pluim 2022-10-05 13:51 ` Eli Zaretskii 1 sibling, 0 replies; 24+ messages in thread From: Robert Pluim @ 2022-10-05 13:31 UTC (permalink / raw) To: Felix Dietrich; +Cc: help-gnu-emacs >>>>> On Wed, 05 Oct 2022 14:32:04 +0200, Felix Dietrich <felix.dietrich@sperrhaken.name> said: Felix> But “xfaces.c:merge_face_ref” (which produces the error message) has a Felix> “struct window w” parameter. I believe in cases where it is not NULL, Felix> which it isnʼt when running the above code, this could be used to derive Felix> the buffer and the bufferʼs position using the struct members “contents” Felix> and “pointm’: 1. “contents” stores, for leaf windows, the windows Felix> buffer; its descriptions mentions other possible value types it may hold Felix> [1]; I do not know in how far these other types have to be considered Felix> here. 2. “pointm” refers to a marker holding the current buffer Felix> position in window; its description states that it is “used only when Felix> the window is not selected”. Therefore, it is possible that, if the Felix> window “w” is the selected one, the point would have to be taken from Felix> another source (perhaps the “PT” macro in “buffer.h”). Weʼre not necessarily examining the faces of the character at (point), weʼre going through redisplay of the buffer, I thought? Felix> Also note that, if the position would be added to the log entry, Felix> multiple log entries would not be merged anymore. Additionally, with Felix> the code above, the position is actually after the text (at Felix> ‘point-max’); therefore, this might not be useful information to add. Felix> I am not sure if the whole thing is worth the effort or would complicate Felix> the creation of a simple log entry for a, hopefully, rare case to much. Itʼs more effort than Iʼm willing to go to, at least :-) Felix> Anyway, perhaps, if there is any interest in adding information to the Felix> “Invalid face attribute” log message, further discussion should move to Felix> a wishlist bug report? Yes. That will get it in front of people who know the relevant code better than I do. Robert -- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 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 1 sibling, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2022-10-05 13:51 UTC (permalink / raw) To: help-gnu-emacs > From: Felix Dietrich <felix.dietrich@sperrhaken.name> > Cc: help-gnu-emacs@gnu.org > Date: Wed, 05 Oct 2022 14:32:04 +0200 > > 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’: Face merging has nothing to do with point, it just considers the face attributes. The commentary to merge_face_ref says how the window pointer is used: /* Merge face attributes from the lisp `face reference' FACE_REF on frame F into the face attribute vector TO as appropriate for window W; W is used only for filtering face specs. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you want to understand what that filtering is about, look at filter_face_ref, where you will clearly see that it never accesses the window's buffer or its point. So when this function is called, there's no reason to believe that the buffer position of point has anything to do with the offending face. The most frequent face merging is performed by redisplay, which doesn't move point and doesn't make the window on whose display it is working the selected window. > 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? Definitely. This discussion doesn't belong to the help list. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 2022-10-05 13:51 ` Eli Zaretskii @ 2022-10-06 14:58 ` Felix Dietrich 0 siblings, 0 replies; 24+ messages in thread From: Felix Dietrich @ 2022-10-06 14:58 UTC (permalink / raw) To: help-gnu-emacs Eli Zaretskii <eliz@gnu.org> writes: > Face merging has nothing to do with point, it just considers the face > attributes. The commentary to merge_face_ref says how the window > pointer is used: Robert Pluim <rpluim@gmail.com> writes: > Weʼre not necessarily examining the faces of the character at (point), > weʼre going through redisplay of the buffer, I thought? Uh, I blundered there in my examination and my thinking: when I ran Emacs in a debugger with a breakpoint on “xfaces.c:merge_face_ref”, the breakpoint was hit when I moved the cursor into or out of a position with text that had an invalid property, and I made, from a position of lacking understanding, a wrong assumption. Thanks to you two for clearing that up. > If you want to understand what that filtering is about, look at > filter_face_ref, where you will clearly see that it never accesses the > window's buffer or its point. > > So when this function is called, there's no reason to believe that the > buffer position of point has anything to do with the offending face. > The most frequent face merging is performed by redisplay, which > doesn't move point and doesn't make the window on whose display it is > working the selected window. Thank you for the clarification. >> 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? > > Definitely. This discussion doesn't belong to the help list. The bug report can be found here: bug#58312 <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58312> -- Felix Dietrich ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 2022-09-25 13:00 ` Emanuel Berg 2022-09-26 9:04 ` Eric S Fraga @ 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 1 sibling, 2 replies; 24+ messages in thread From: Stefan Monnier via Users list for the GNU Emacs text editor @ 2022-09-28 11:41 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg [2022-09-25 15:00:31] 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. A better option might be to include the position of the problem, so you can then go and investigate the text properties and overlays at that position. Stefan ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 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 1 sibling, 0 replies; 24+ messages in thread From: Robert Pluim @ 2022-09-28 15:04 UTC (permalink / raw) To: help-gnu-emacs; +Cc: Stefan Monnier >>>>> On Wed, 28 Sep 2022 07:41:38 -0400, Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> said: Stefan> Emanuel Berg [2022-09-25 15:00:31] wrote: >> Sounds like that error message should be changed to include >> what face causes trouble, if possible? Stefan> IIUC this message comes when the face is not a symbol but a plist of Stefan> properties, so there's a good chance that printing the face will just Stefan> say (:foreground nil) and thus won't help you. A better option might be Stefan> to include the position of the problem, so you can then go and Stefan> investigate the text properties and overlays at that position. Yes, (:foreground nil) is what you get. And by the time the log is produced in `merge_face_ref', thereʼs no trace left of the position weʼre looking at. Robert -- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 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 1 sibling, 1 reply; 24+ messages in thread From: Emanuel Berg @ 2022-09-29 16:32 UTC (permalink / raw) To: help-gnu-emacs 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? 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? -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 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 0 siblings, 2 replies; 24+ messages in thread From: Felix Dietrich @ 2022-10-03 19:19 UTC (permalink / raw) To: help-gnu-emacs [-- 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 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 2022-10-03 19:19 ` Felix Dietrich @ 2022-10-03 22:46 ` Emanuel Berg 2022-10-04 11:06 ` Felix Dietrich 1 sibling, 0 replies; 24+ messages in thread From: Emanuel Berg @ 2022-10-03 22:46 UTC (permalink / raw) To: help-gnu-emacs Felix Dietrich wrote: >>> 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. Okay, what use cases are they? And even so, if they are anonymous faces, why are they producing a warning for an invalid value, which should then be part of their definition? Shouldn't that be an error? Or can you somehow refer to the face, even if it is anonymous, an make it complete at some later stage? Oh no, this whole thing ... -- underground experts united https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 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 1 sibling, 1 reply; 24+ messages in thread From: Felix Dietrich @ 2022-10-04 11:06 UTC (permalink / raw) To: help-gnu-emacs Felix Dietrich <felix.dietrich@sperrhaken.name> writes: > Emanuel Berg <incal@dataswamp.org> writes: > >> Isn't it better to initialize the faces first, and if it is >> attempted to define [a face] 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 I was not correct with my assumption: when you ‘defface’ a face with an invalid :foreground value this will produce an error, but enough of the face with the invalid value remains that later creations of new frames using ‘make-frame-command’ will fail with that same error: #+begin_src emacs-lisp (progn (ignore-errors (defface my/test03 '((t . (:foreground nil))) "test face")) (make-frame-command)) #+end_src This produces the error “(wrong-type-argument stringp :bla)”. -- Felix Dietrich ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 2022-10-04 11:06 ` Felix Dietrich @ 2022-10-05 11:29 ` Felix Dietrich 0 siblings, 0 replies; 24+ messages in thread From: Felix Dietrich @ 2022-10-05 11:29 UTC (permalink / raw) To: help-gnu-emacs Felix Dietrich <felix.dietrich@sperrhaken.name> writes: > Felix Dietrich <felix.dietrich@sperrhaken.name> writes: > >> Emanuel Berg <incal@dataswamp.org> writes: >> >>> Isn't it better to initialize the faces first, and if it is >>> attempted to define [a face] 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 > > I was not correct with my assumption: when you ‘defface’ a face with an > invalid :foreground value this will produce an error, but enough of the > face with the invalid value remains that later creations of new frames > using ‘make-frame-command’ will fail with that same error: > > #+begin_src emacs-lisp > (progn > (ignore-errors > (defface my/test03 '((t . (:foreground nil))) "test face")) > (make-frame-command)) > #+end_src > > This produces the error “(wrong-type-argument stringp :bla)”. I copied the wrong snippet from my experiments. It should have been this: #+begin_src emacs-lisp (progn (ignore-errors (defface my/test '((t . (:foreground :bla))) "test face")) (make-frame-command)) #+end_src -- Felix Dietrich ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 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-25 14:01 ` Eli Zaretskii 2022-09-25 15:53 ` Eric S Fraga 2022-09-25 14:26 ` Felix Dietrich 2 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2022-09-25 14:01 UTC (permalink / raw) To: help-gnu-emacs > From: Eric S Fraga <e.fraga@ucl.ac.uk> > Date: Sun, 25 Sep 2022 13:03:03 +0100 > > 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. All web searches > lead me to specific packages that have had this error in the past (none > of which I use). Can you run Emacs under GDB? If so, put a breakpoint on the line in xfaces.c which emits this message, and use the backtrace to find out which face causes it. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 2022-09-25 14:01 ` Eli Zaretskii @ 2022-09-25 15:53 ` Eric S Fraga 2022-09-25 16:06 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Eric S Fraga @ 2022-09-25 15:53 UTC (permalink / raw) To: help-gnu-emacs Hi Eli, On Sunday, 25 Sep 2022 at 17:01, Eli Zaretskii wrote: > Can you run Emacs under GDB? If so, put a breakpoint on the line in > xfaces.c which emits this message, and use the backtrace to find out > which face causes it. Currently playing around by disabling packages to try to track this down but I will try this if all else fails. It's been years (decades?) since I last used gdb... Thank you, eric -- Eric S Fraga via gnus (Emacs 29.0.50 2022-09-22) on Debian 11.4 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 2022-09-25 15:53 ` Eric S Fraga @ 2022-09-25 16:06 ` Eli Zaretskii 2022-09-25 17:20 ` Eric S Fraga 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2022-09-25 16:06 UTC (permalink / raw) To: help-gnu-emacs > From: Eric S Fraga <e.fraga@ucl.ac.uk> > Date: Sun, 25 Sep 2022 16:53:52 +0100 > > On Sunday, 25 Sep 2022 at 17:01, Eli Zaretskii wrote: > > Can you run Emacs under GDB? If so, put a breakpoint on the line in > > xfaces.c which emits this message, and use the backtrace to find out > > which face causes it. > > Currently playing around by disabling packages to try to track this down > but I will try this if all else fails. It's been years (decades?) since > I last used gdb... If you have many dozens of packages to try disabling, it might be faster to ask for instructions for running under GDB, because that will give you an instant and accurate answer. Your call. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 2022-09-25 16:06 ` Eli Zaretskii @ 2022-09-25 17:20 ` Eric S Fraga 0 siblings, 0 replies; 24+ messages in thread From: Eric S Fraga @ 2022-09-25 17:20 UTC (permalink / raw) To: help-gnu-emacs On Sunday, 25 Sep 2022 at 19:06, Eli Zaretskii wrote: > If you have many dozens of packages to try disabling, it might be > faster to ask for instructions for running under GDB, because that > will give you an instant and accurate answer. Thank you. In any case, I have now found it (working on the last instantiated package first basis ;-)). -- Eric S Fraga via gnus (Emacs 29.0.50 2022-09-22) on Debian 11.4 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 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-25 14:01 ` Eli Zaretskii @ 2022-09-25 14:26 ` Felix Dietrich 2022-09-25 15:51 ` Fraga, Eric 2 siblings, 1 reply; 24+ messages in thread From: Felix Dietrich @ 2022-09-25 14:26 UTC (permalink / raw) To: Eric S Fraga; +Cc: help-gnu-emacs Hi Eric, 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. I am just going to brainstorm some ideas here: 1. Go through every buffer and check for every buffer position whether any anonymous face set in a text property or overlay property has a :foreground attribute that is nil. This might give you an idea about which packages could be responsible. I do not have code for that, but could probably concoct something. 2. Grep through your configuration and your installed packages for ":foreground" and see if it is paired with nil somewhere. One of the various functions to add text properties [1] or ‘overlay-put’ should be close by. 3. Deactivate groups of packages and see what happens. Might be a bit to tedious and error prone if you have a lot installed and need to manage their shared dependencies. 4. A bit of a harebrained sledgehammer approach (which might lead nowhere): run Emacs in a debugger, set a watchpoint on ‘add_to_log’ being called with a ‘format’ argument starting with "Invalid face attribute", then, on break, analyse the stack, and see if you can figure out the culprit. Footnotes: [1] (info "(elisp) Changing Properties") <https://www.gnu.org/software/emacs/manual/html_node/elisp/Changing-Properties.html> -- Felix Dietrich ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: how to track down "invalid face attribute" errors? 2022-09-25 14:26 ` Felix Dietrich @ 2022-09-25 15:51 ` Fraga, Eric 0 siblings, 0 replies; 24+ messages in thread From: Fraga, Eric @ 2022-09-25 15:51 UTC (permalink / raw) To: Felix Dietrich; +Cc: help-gnu-emacs@gnu.org Hi Felix, Thank you for the various suggestions. They are all rather cumbersome but all make sense as well. I'm doing the disable various packages in turn at the moment. Thanks again, eric -- Eric S Fraga via gnus (Emacs 29.0.50 2022-09-22) on Debian 11.4 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2022-10-06 14:58 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).