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.
Related
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.
How do you go about solving this problem?
Suppose I want to write a function that does the following: if the user has library X installed, then use function X-function, otherwise - skip?
What I tried:
(when (symbol-function 'X-function)
(X-function))
I'm getting a warning for this code - so what is the right way?
How about this:
(when (fboundp 'X-function)
(X-function))
The docs at http://www.gnu.org/software/emacs/manual/html_node/elisp/Function-Cells.html says about symbol-function
If the symbol's function cell is void, a void-function error is signaled.
I'm guessing that is what you are seeing. On the other hand, fboundp just returns t or nil depending on whether the function exists.
The way to suppress this compiler warning is with something like:
(declare-function X-function "ext:X-library.el")
(when (fboundp 'X-function)
(X-function))
Here X-library is the name of the library that X-function is defined in when the library is there. The byte-compiler will then do the following:
It will look for the library in the load path.
If it finds it, it will check that the function has been defined.
If it does not find the library it will assume that it will be when the library is there and pass on without error.
Thus if there is no X-library it won't complain, but if there is one and it does not define the function then it will. This means that if an updated version of the library does not contain X-function then you will know when you try to re-compile your code.
If you look up the documentation for declare-function you will find that it can also check the argument list of functions.
Incidentally If you get similar warnings about undeclared variables you can suppress these with:
(defvar X-variable)
However it is important not to set the variable even if you know what value the library sets it to as this could change in a later version.
This gives you one version of the program that works whether or not X-library is present. You might prefer to have two versions, one for when X-library is present and one for when it is not. This can be done with a macro:
(defmacro run? (function &rest args)
"Expand to function call if function exists."
(when (fboundp `,function)
`(,function ,#args)))
Now instead of a call like:
(X-function a1 a2 a3)
You write:
(run? X-function a1 a2 a3)
If you compile it with X-library present this expands to the call to X-function. If the library is not present then it expands to nothing at all. You will not need the declare-function in any case. This gives two different versions, but it should be more efficient because the decisions as to whether the library is there or not are taken at compile time not run time.
One small caveat. If you go for this second solution you must either compile the whole program in the X-library environment or outside it. If you try loading the library half way through the program then when interpreted it will work as you might expect with the macro expanding differently before and after the load. But in a compiled program a macro is only expanded once. The test test for the library is in code that does the expanding not in the expansion, so the macro will not work the same before and after the load.
Another case when you can get the warning that a function cannot be found is when you define a function programmatically and use fset to set it. The following example illustrates this and what to do about it:
(eval-and-compile
(fset 'my-function1 (lambda () nil)))
(my-function1)
(fset 'my-function2 (lambda () nil))
(my-function2)
(my-function3)
(eval-and-compile
(fset 'my-function3 (lambda () nil)))
If you compile this you get the warnings:
Warning: the function `my-function2' is not known to be defined.
and:
Warning: the function `my-function3' might not be defined at runtime.
The second warning goes away if you re-compile the code a second time in the same Emacs session, but the first doesn't.
What is happening here is this: When the compiler sees eval-and-compile, it first evaluates the body of the in the current Emacs session and then compiles it. Having evaluated the code, Emacs knows about the programmatically defined function.
In the case of function1, the byte compiler sees the function call after Emacs has evaluated the form and so you don't get any warnings.
In the case of function2 the byte compiler never knows the functions is defined so you always get a warning.
In the case of function3, the first time round, the bite compiler doesn't know the function exists when it sees the function call. By the end of the compilation it knows the function exists but it isn't intelligent enough to work out how it knows so you get a different warning. However, if you re-compile it in the same Emacs session, it does know so the warning goes away.
Note that eval-and-compile, like eval-with-compile, look like a progn to the Emacs interpreter.
I'm trying to augment the etags-select functions so it will fall-back to a normal find-tag if find-tag at point failed. The code I've tried is:
(defun my-etags-find-tag ()
"Find at point or fall back"
(interactive)
(unless (etags-select-find-tag-at-point)
(etags-select-find-tag)))
(global-set-key (kbd "C-f") 'my-etags-find-tag)
However this fails when point is not at a valid tag. Instead I get a error thrown by etags-select-find-tag-at-point:
etags-select-find-tag-at-point: Wrong type argument: char-or-string-p, nil
In this case I just have to repeat the test done by etags-select-find-tag-at-point:
(defun my-etags-find-tag ()
"Find at point or fall back"
(interactive)
(if (find-tag-default)
(etags-select-find-tag-at-point)
(etags-select-find-tag)))
But it does seem a little redundant. Is it possible to trap exceptions and do alternate processing in elisp?
Try ignore-errors; eg,
(unless (ignore-errors (etags-select-find-tag-at-point))
(etags-select-find-tag))
Normally, (ignore-errors body) returns whatever body returns; when there's error, it returns nil.
Also look at condition-case for more general condition handling.
If you have Elisp info manual installed, you can get more details from
C-hSignore-errors.
Edit:
I failed to consider the possibility that the function may return nil on success; so we probably need
(unless (ignore-errors (or (etags-select-find-tag-at-point) t))
(etags-select-find-tag))
Without modifying the original source code of etags-select.el, I see it the more reasonable option, even when it calls twice to find-tag-default. You can cheat the dynamic environment within the call to avoid the repetition of the call by memoizing it with something like:
(defun my-etags-find-tag ()
"Find at point or fall back"
(interactive)
(let ((ftd (find-tag-default)))
(flet ((find-tag-default () ftd))
(if (find-tag-default)
(etags-select-find-tag-at-point)
(etags-select-find-tag)))))
EDIT: OK, as per your request, an explanation of the code. First, note that this code achieves both questions:
It does not fail
It is more efficient than the code you show (the one you say it is redundant).
Why is it more efficient? The problem with your redundant code is that you call find-tag-default to see if it is nil, and, if it is, you call etags-select-find-tag-at-point. This function calls again to find-tag-default to obtain a default value. What my code does is to cache the value of find-tag-default by redefining the function by being just the value you calculated. The flet does that, so when etags-select-find-tag-at-point calls find-tag-default, the calculated value is returned without any further processing.
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.
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...