Good day, when load any source file into editor i get following message:
File mode specification error: (wrong-type-argument stringp nil)
and flymake simply not working then.
Starting with --init-debug does not improve anythong. Any idea how to debug the cause of problem ?
This general error is thrown when a Lisp function actually expects a string argument but receives a nil.
Try setting (setq debug-on-error t) at the top of your .emacs to get a stack-trace showing you which string is nil. In case the error is caused by FlyMake settings in your .emacs: here is a good introduction.
The deeper reason for wrong-type-argument exceptions is that Lisp functions have no prototypes and cannot rely on the interpreter; they're always defined and hence need to parse their arguments on their own.
The Emacs Lisp interpreter itself does not perform type checking on
the actual arguments passed to functions when they are called. [...]
It is therefore up to the individual function to test whether each
actual argument belongs to a type that the function can use.
For more information see Type Predicates in the Emacs Lisp Reference Manual.
Related
I'm getting the following error when starting emacs: (as shown from the messages buffer):
c-font-lock-fontify-region: Symbol's function definition is void: nil
How do I track down what exactly is causing the error in this function? debug-on-error is true, but it still doesn't give any more information here.
The symbol is nil.
It does not name a function.
Generally speaking, to debug the error, you need to set debug-on-error to t and look at the *Backtrace* buffer.
If no *Backtrace* buffer appears (which is the case here), this means that the caller of the function which signals the error catches the error. You would need to chase the code looking for condition-case and disable it. Good luck with that :-(
Looking at the c-font-lock-fontify-region definition in progmodes/cc-mode.el, I see there
(funcall (default-value 'font-lock-fontify-region-function)
new-beg new-end verbose)
which can easily cause the error if (default-value 'font-lock-fontify-region-function) is nil.
In order to get a backtrace even if the error is caught by a condition-case you can try to (setq debug-on-signal t). This will trigger in many cases which aren't bugs, so it's something to use only occasionally because it can really get in the way, but it might be helpful in this particular case.
Byte compiling emacs lisp is pretty useful, as it generates compiler warnings that, though sometimes cryptic, always point at an error or unfinished tasks, such as missing imports or unimplemented functions.
However, I cannot find a way to generate custom compiler-warnings that integrate well with the *Compile-Log* buffer, i.e. that show the position of the error like
mymodule.el:247:1:Warning: Unused lexical variable `file-name'
E.g. I'm using the subsequent code for placing todo items that raise compile-time messages:
(eval-when-compile
(defmacro TODO (string)
`(eval-when-compile
(message "TODO: %s" ,string))))
However, I cannot find a way to add information (at compile-time) on
file name
line-number
At load-time the variable load-file-name is available, but it is nil at compile-time. The variable default-directory is defined at compile-time but doesn't help in this case.
For the line-number I know no method at all.
When using (warn ...) instead, I get something like
Warning (emacs): TODO: Complete or remove
i.e. no position information at all. If I use (error ...), I get the line number etc displayed automatically, but compilation stops instead of showing all errors and warnings, so it is not a viable solution either.
Update
A partial solution seems to be
(funcall (if byte-compile-current-file 'byte-compile-warn 'warn) FORMAT [ARGS ...])
You need to use the internal variables byte-compile-current-file (the name of the file being compiled) and byte-compile-read-position (the character position at the start of the last read).
Alternatively, you can try the function byte-compile-warning-prefix which inserts the file:line prefix in the *Warnings* buffer.
Either way, you are on your own, messing with the Emacs internals; SO is your only friend. :-)
Indeed, that was a problem. And even byte-compile-read-position is fairly poor because it's not yet up-to-date when the macro is expanded. In Emacs's trunk there is macroexp--warn-and-return, tho as the -- implies, it's currently still considered internal. E.g.
(defmacro TODO (string)
(macroexp--warn-and-return
(format "TODO: %s" string)
nil))
To understand how to use it, you have to understand that it works by returning a special piece of code which makes the byte-compiler later on (when the line-info is available) emit the message.
the error is
Warning: ad-Orig-kill-new called with 3 arguments, but accepts only 1-2
I added the code into .emacs following the guide Warning when I revert from desktop session. Emacs
(ad-deactivate 'kill-region)
but after restart emacs, it showed me the error message:
Symbol's function definition is void: ad-deactivate
How can I do to cope with the error: > Warning: ad-Orig-kill-new called with 3 arguments, but accepts only 1-2
thank you for your help
It's hard to be certain without more information about your emacs version and your load files, but if the function's definition is void it sounds like advice.el hasn't been loaded yet. You might try changing your .emacs file so it is loaded explicitly before calling the function; something like this:
(require 'advice)
(ad-deactivate 'kill-region)
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?
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
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.
For me, it happened because I had an extra pair of () parenthesis around a function body I wrote. I guess that makes lisp attempt to execute the return value of the function body. So pay attention to your parenthesis count!
I've been getting this error in emacs whenever I type anything in certain buffers:
c-forward-sws: Wrong type argument: stringp, nil
It seems to be a syntax highlighting thing; I'm getting it in a buffer that's in sh-mode whenever I type anything -- even return on an empty line. I have also occasionally gotten it in a C++-mode buffer but I don't remember the specific line, nor can I reproduce it in such a mode.
I have not changed my .emacs lately (that I can recall).
Any ideas what the problem is? The function is defined in cc-engine.el but I'm having a hard time figuring out the context.
Chances are good that you have auto-fill-mode on and the auto-fill-function is c-do-auto-fill, which doesn't work so well for other languages. Either turn auto fil off (M-x auto-fill-mode) or change the value of the fill function.
You should be able to debug the entry to auto-fill-mode explicitly with M-x debug-on-entry RET auto-fill-mode and see what's invoking it. There's probably a hook that's turning it on, which will appear in the stack trace.
[Update]
I found that the global value of auto-fill-function was being set (it's supposed to always be buffer-local). The result is that all buffers default to using auto fill with that function. I haven't determined how the global value is being set, but it can be cleared up using (setq-default auto-fill-function nil).
To figure out the problem, you need to do a little more investigation. What you've provided isn't enough (unless the answerer has already seen the specific problem).
The first step is generally to set the variable debug-on-error to t. This will provide a stack trace with more information (generally telling you which expression inside the function is causing the problem).
If you can reliably reproduce the problem, then don't set the above variable, but instead go to the function definition (M-x find-function c-forward-sws RET), and set it up for debugging with M-x edebug-defun. Then do what causes the error and step through the code. The debugger is pretty intuitive if you're familiar with looking at lisp, and the documentation can be found on this info page.
At the very least, adding the stack trace might provide enough information to lead to an answer, though likely it'll take a test case to reproduce the problem...