Seeking help with a debugging problem

So today I've found that when displaying a particular window (for what it's worth, it belongs to [helpful](https://github.com/Wilfred/helpful)) I am repeatedly getting an error message: ``` Invalid face attribute :family nil ``` There is nothing obviously untoward actually happening, but the error message pops up constantly while I'm navigating in this window, so it's extremely annoying, and I'd love to at least understand what's going on. Especially considering that the likelihood of the bug actually being in `helpful` is not very high, it's more probable that it's somewhere else in my config -- I've seen it before, just less often. By digging through Emacs source, I've been able to find that the actual source of the message is `face-attributes-as-vector`, a function defined in `xfaces.c`. Deep in the C code. That's the only place anywhere I can find this error message text. Now I'm trying to trace the calls to it to find out just where and what resulted in the nil `:family` and nothing seems to work, neither `trace.el` nor Edebug -- it just prints the message and goes off on its merry way. Manually advising it with something to the tune of `(defun trace-face-attrs (a-plist) (message "Tracing: %s" a-plist)) (advice-add 'face-attributes-as-vector :before #'trace-face-attrs)` doesn't result in advice function getting called either. It's like the function isn't actually getting called at all. How do I get at the root of this damned thing?

Have you already enabled debug-on-error, e.g. via `M-x toggle-debug-on-error`?

That was the *first* thing I did. No error gets thrown, no debug pops up.

Goodo. :-) So the next thing might be to try setting the `debug-on-message` variable to e.g. "Invalid face attribute".

It's pretty funny actually: It trips on the output from the `setq` I used to set it, consistently, but does *not* trip on the actual message.

Dang. Does `M-x list-faces-display` work without error?

Yep, tried that too. No errors show up for either `list-faces-display` or `counsel-faces` for that matter. Oh, and while we're at it: I turned on tracing on every `DEFUN` that `xfaces.c` defines and while some of them *do* fire, none of them return errors.

Okay. Well, the fact that you get this error regularly whilst using `helpful` suggests to me that it's to do with one of the faces that `helpful` uses, which seem to be `helpful-heading`, `font-lock-comment-face`, `font-lock-constant-face`, `font-lock-builtin-face`, `font-lock-variable-name-face` and `highlight`. Maybe you could check the attributes of each of these manually?

(dolist (f '(helpful-heading font-lock-comment-face font-lock-constant-face font-lock-builtin-face font-lock-variable-name-face highlight)) (describe-face f)) no errors, windows describing faces popping up as expected. (mapcar (lambda (f) (face-attribute f :family)) '(helpful-heading font-lock-comment-face font-lock-constant-face font-lock-builtin-face font-lock-variable-name-face highlight)) -> (unspecified unspecified unspecified unspecified unspecified unspecified) And still no errors. For that matter, all of these faces are also used everywhere else except `helpful-heading`... And yes, I tried redefining `helpful-heading` with `:inherit default`, no change.

How very odd. i've got nothing else, sorry - hope someone else is able to help, because i'm intrigued.

Well, thanks for trying anyway. Watch this space for further adventures in debugging. :)

`debug-on-error` is inhibited inside of certain hooks. Since this is happening while you interact with the buffer, that suggests that it may be occurring during a pre or post-command-hook, or perhaps one from after-change-functions. So check to see what hooks you have set. Here's a trick for re-enabling debug-on-error inside a particular hook: (advice-add 'my-suspicious-hook :around (lambda (func) (condition-case err (funcall func) ((debug error) (signal (car err) (cdr err))))))

ELISP> (advice-add 'post-command-hook :around ... ELISP> (advice-add 'pre-command-hook :around ... ELISP> (advice-add 'after-change-functions :around ... Well, it's certainly none of those three, but this sounds promising. What I noticed is that the message never appears while I move the cursor horizontally along the line. It's always when it's moving up and down. But I don't know enough about all the hooks to say which one could it be...

Ah theeere we go. (message "my family is %s" (all-the-icons-icon-family-for-mode major-mode)) -> my family is nil The culprit was a spaceline segment which shows an icon according to major mode. `all-the-icons` does not have an icon for `helpful`, and for a few other modes too -- which is why I saw this message before, on something else. How the hell does spaceline manage to prevent debugging so hard is an open question, though. **EDIT**: For whoever comes googling, how I found the right hook -- I went looking for how to find which hooks run after a certain command, found [this StackExchange answer](https://emacs.stackexchange.com/questions/19578/list-hooks-that-will-run-after-command/), checked `view-lossage` for which commands I was actually running when I triggered the error message, and ran that snippet on `next-line`. `spaceline-pre-hook` was the only one that came up. It was empty, but it did point me in the right direction.

>How the hell does spaceline manage to prevent debugging The mode-line is updated at a low level, on redisplay. `:eval` forms in the mode-line have their errors suppressed as well, e.g. (setq mode-line-format '("MODELINE" (:eval (format "GOT: %d" (/ 1 0))))) will run without error, just silently omitting the results of the `:eval` form! Mode-line is another good thing to check with mystery "after many commands" errors that evade debug-on-error.

[deleted]

I've got the same issue.... pulling my hair out... (not using helpful)