8

After using Emacs for some time, the message Invalid face reference: quote starts popping up in my message buffer. I'm not sure what causes it to start appearing.

  • debug-on-message doesn't do anything (this is an error in the redisplay code)
  • debug-on-error doesn't work either (for the same reason)
  • grepping my .emacs.d for quote or ' returns way too many results
  • The problem is probably caused by a specific mode, but I don't know which, so debugging with -Q is tricky

What tricks could I use to locate the issue? Would a carefully crafted grep command work? Can I make font-lock output more information? Can I edit part of the Emacs C sources to get a backtrace if that message appears?

Improve this question
8
  • @elethan: Can you explain your edit?
    – Clément
    Jan 25, 2016 at 18:53
  • Just a minor grammar change: "information" to "informative", since "information" is not an adjective and can't be modified by "more". Or perhaps you meant to write: "make font-lock output show more information", that would make sense too, but mean the same thing as my edit. I just had to read the sentence a few times because of the error, so I thought I would clarify. Too nit-picky?
    – elethan
    Jan 25, 2016 at 18:59
  • 1
    No, I meant to write what I wrote :) I was using "output" as a verb, not as an noun (as a noun it would have required a possessive: "font-lock's output")
    – Clément
    Jan 25, 2016 at 19:21
  • Ah, you are right! It is ambiguous, and I didn't consider that interpretation. In which case my edit is ambiguous too! If you read "output" as a verb, then mine seems like an error at first glance. I will change it back (I hate English sometimes...)
    – elethan
    Jan 25, 2016 at 19:25
  • Indeed, both are ambiguous. I'd be happy with "print" or "produce" instead of output, if you like that better :)
    – Clément
    Jan 25, 2016 at 19:29

3 Answers 3

Reset to default
4

You can use font-lock-studio to debug this. It's a debugger for font-lock keywords that let you single-step each step in the font-lock engine, run to breakpoints etc. Unlike the real font-lock, it enters the elisp debugger when an error occurs (if debug-on-error is non-nil).

Improve this answer
1
  • Thanks for the pointer. This looks great; I'll give it a go next time I see the error.
    – Clément
    Jan 27, 2016 at 14:55
0

Start by finding a minimal way to reproduce the problem. Maybe you can record keystores (is it called "lossage"?) to do this?

Have you tried the basic trick bisecting your configuration to locate which package/mode the problem comes from? I.e. disabling half, seeing if the problem is still there (if so, disable half of what is left, if not, disabling the other half, and so on).

Improve this answer
4
  • 1
    No, because it isn't clear how to make the problem appear; after a while I the message will start popping up; it could be because of a particular mode, but I'm not sure which.
    – Clément
    Jan 25, 2016 at 22:33
  • That would be good to include in your question. You say it appears frequently up there, which lead me to think that it was easy to reproduce...
    – asjo
    Jan 26, 2016 at 20:03
  • I updated the question
    – Clément
    Jan 26, 2016 at 21:36
  • Great; I updated the answer.
    – asjo
    Jan 26, 2016 at 22:50
-1

The approach I've taken for similar things is to grep the Emacs and Elpa source code for the error to find where it might be triggered, find some likely looking functions, then instrument them to invoke edebug.

http://www.gnu.org/software/emacs/manual/html_node/elisp/Instrumenting.html#Instrumenting

Then when they get triggered, step through the code, look at the call stack, etc, and try to figure out where things are going wrong.

I couldn't find anything for "Invalid face reference", so this approach might not work in this case, but "Invalid face" had a couple of hits in the Emacs source code:

C:\apps\emacs\lisp>grep -ir "invalid face" *

ChangeLog.10:   always highlighted with the inverted invalid face.  It can
ChangeLog.14:   `face-id', which already signals an error for invalid faces.
ChangeLog.8:    The code relied on the fact that Emacs ignored invalid faces in
cus-edit.el:    (error "Invalid face %S" face))
cus-edit.el:                        :error (format "Invalid face: %S"
cus-edit.el:(add-to-list 'debug-ignored-errors "^Invalid face:? ")
Binary file cus-edit.elc matches
faces.el:         (t nil))))                    ; Invalid face value.
faces.el:         (t nil))))                    ; Invalid face value.
gnus/ChangeLog: place holder since this gives `Invalid face reference: nil' messages.

In that file, customize-face can trigger that error.

Not sure if that's where your error is happening - it could be in an Elpa package also, but that's one possible approach.

Improve this answer
1
  • 1
    I don't think this applies here. This error comes from the redisplay code in C, and the debugger cannot start while redisplay code is executing.
    – Clément
    Jan 27, 2016 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.