What does it mean when emacs tells me "File mode specification error"?

Question

This is the most useless error message I have ever seen.

I think it translates to .. "error".

The full error message from the *Messages* buffer is:

File mode specification error: (wrong-type-argument characterp "string value here")

I think the latter part of that message means that emacs was expecting a character and got a string.

But how do I go about diagnosing just what it means when emacs tells me "File mode specification error" ? and how do I narrow down where this error is originating?

How are these two errors (file mode error, expecting character and got string) related?

Answer 1

Use M-x toggle-debug-on-error RET to drop into the debugger when this (or any) error occurs -- assuming that this is a proper error, and not just a message. That gives you the stack trace, so you can figure out what caused it, and proceed from there (possibly with edebug, once you've determined which function(s) to instrument, but you can do plenty with the regular debugger).

Standard debugger commands: M-: (info "(elisp) Debugger Commands") RET

Main manual entry for debugging lisp (including edebug): M-: (info "(elisp) Debugging") RET

FYI, rgrep tells me that the only instance of the string "File mode specification error" in the *.el files for NTEmacs 23.2.1 appears in the normal-mode function definition:
M-x find-function RET normal-mode RET

Answer 2

You might want to say what version of Emacs you are using.

If it's GNU Emacs 23, then the relevant code is in the function normal-mode in files.el and looks like this:

(report-errors "File mode specification error: %s"
  (set-auto-mode))

So the function set-auto-mode (or some function called from there) is signalling the wrong-type-argument error and normal-mode is adding the text File mode specification error in an attempt to help you track it down, but sadly it's not helping here, because the function of set-auto-mode is to determine which major mode a buffer should have, and then turn on that mode. I expect it's the mode itself that's signalling the error.

So phils' advice to turn on debug-on-error and look at the backtrace is a good one: that should give you a clue as to what's going on.