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?

Clément
  • 3,924
  • 1
  • 22
  • 37
  • @elethan: Can you explain your edit? – Clément Jan 25 '16 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 '16 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 '16 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 '16 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 '16 at 19:29
  • Really I think it is fine the way you had it - it is understandable with either interpretation, and ultimately it is correct so I would say just leave it. Or we can ask a new question here: http://english.stackexchange.com/ haha! – elethan Jan 25 '16 at 19:32
  • Does `debug-ignored-errors` contain something like `"^Invalid face"`? If that's the case, the likely reason `debug-on-error` doesn't work is that the error gets suppressed by `debug-ignored-errors`, and removing that from `debug-ignored-errors` might allow you to get a proper backtrace. – Kirill Apr 19 '17 at 20:03
  • I believe I had this issue and proposed a pull request fixing it: https://github.com/hniksic/emacs-htmlize/pull/42 - would be nice if you guys could check if that works for you also. – Renato Jan 07 '23 at 22:24

3 Answers3

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).

Lindydancer
  • 6,095
  • 1
  • 13
  • 25
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).

asjo
  • 1,037
  • 8
  • 12
  • 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 '16 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 '16 at 20:03
  • I updated the question – Clément Jan 26 '16 at 21:36
  • Great; I updated the answer. – asjo Jan 26 '16 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.

Brian Burns
  • 1,577
  • 14
  • 15
  • 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 '16 at 14:54