A few times each day, I receive an ispell error (like the following) that is corrected by restarting Emacs. Any ideas on how to further troubleshoot this type of error would be greatly appreciated.
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
ispell-command-loop(("Brae" "Br ea" "Br-ea" "Bra" "Bread" "Break" "Bream"
"Brew" "Bret" "Bred" "Area" "Urea") nil "Brea" 2229 2233)
ispell-process-line("^Brea, CA ~ 92821\n" nil)
ispell-region(1 6771)
ispell-buffer()
ispell()
call-interactively(ispell nil nil)
command-execute(ispell)
The document being spell-checked is in tex-mode (built-in -- i.e., not using AUCTeX). The error (today) comes form a simple address at flush-left:
242 S. Orange Avenue\\
Brea, CA ~ 92821
Try loading ispell.el and then:
Try to provoke the error. After loading the source file (not the byte-compiled file), you will perhaps get a more detailed backtrace, which will tell you better what causes the error. (You apparently already have debug-on-error non-nil.)
If that doesn't tell you enough, then do M-x debug-on-entry ispell-command-loop, and walk through the execution in the debugger. That should show you just what goes wrong - where that function expects a number and hasnil instead.
Based on your better understanding, you will likely know what to do, to either avoid or fix the problem.
If you cannot reproduce the error easily then #2 will probably not be of much help. In that case, you can try examining the code of ispell-command-loop to see if you can figure out where the problem is.
You can also copy that code and insert calls to message at various places, to try to determine where things go wrong when they do go wrong. IOW, provide yourself with some more info than that sparse backtrace.
Maybe someone else has a better idea - mine is pretty much brute force here.
Related
When I attempt to kill Emacs (with save-buffers-kill-terminal) I get the error
End of file during parsing
Looking at the *Messages* buffer, I see:
progn: End of file during parsing
No *Backtrace* buffer shows up, even with debug-on-error set to t.
How do I figure out what is going on?
Recursively bisect your init file to find which part of it leads to the problem.
Yes, this means restarting and quitting Emacs multiple times, but this is a binary search, so it is in fact very fast, even if it is essentially thoughtless. Importantly, it is systematic, which guessing is typically not.
Likewise, if you find that the problem comes from some library that you load: recursively bisect it to find the problem in it.
And as #phils said, check-parens is also your friend.
Ever since I installed emacs24 some tiny insignificant piece of my configuration files stopped working. Since I don't really care about this error and It does not affect me I just want Emacs to shut up about initialization warnings and just open the scratch buffer (as it is it opens a second buffer with some error stuff).
Is there a way to do this without having to sit hours to debug lisp code I don't understand?
I really can't post the configuration file because it's really really big and messy, but this is the warning I get:
Warning (initialization): An error occurred while loading `/home/sofia/.emacs':
Symbol's function definition is void: plist-to-alist
To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file. Start Emacs with the
`--debug-init' option to view a complete error backtrace.
In a nutshell, I don't want to ensure normal operation, I just want one buffer when opening emacs
I'm not saying that it's a good idea to do this (in fact I very much agree with #Carl Groner and #rashimoto that masking errors instead of fixing them is usually a Bad Idea™), but at your own risk try adding the following to the top of your .emacs file:
(setq warning-minimum-level :emergency)
This tells Emacs not to warn you about anything except problems
that will seriously impair Emacs operation soon if you do not attend to [them] promptly.
By contrast, the default value of warning-minimum-level is :warning, which causes Emacs to warn you about
data or circumstances that are not inherently wrong, but raise suspicion of a possible problem.
More info about warnings and options for dealing with them here and here.
I have an org-mode file that I'm trying to export to a Beamer LaTeX PDF through XeTeX. It was working fine last night on this machine, and just as well on another machine on which I edited it afterward. Both are running org-mode 8, Emacs 24, same export process (3 runs of XeLaTeX)
When I synced back to this machine and tried to export again, I got the error Wrong block type at a headline named "". I checked all my headlines and gave them all names, but still got the same result.
Thanks to the wonders of indexed searchable FLOSS code, I immediately found the snippet online:
(env-format
(cond ((member environment '("column" "columns")) nil)
((assoc environment
(append org-beamer-environments-extra
org-beamer-environments-default)))
(t (user-error "Wrong block type at a headline named \"%s\""
raw-title))))
I'm not really solid on elisp at all, though, and I don't know most of what's going on here. From this snippet, what would I do to start debugging? (I realize I can start the emacs debugger, but it's not a PKE meter, I can't just wave it around.)
IMHE the best way to figure out what's wrong when you've found the relevant snippet of code is to use Edebug.
You should read the documentation to learn more about it, but basically here is my procedure:
identify the part of the code that crashes
instrument the code with Edebug (C-uC-M-x)
re-execute the code and go step by step to figure out what's going on (n)
If the problem is in another function, jump to it GOTO 2.
Iterate until you've understood the code and find a way to fix it.
Posting this answer just so that the specific solution to the particular problem the error was flagging is understood.
Apparently the version of Beamer I have on the other machine has a "normal" Beamer environment that specifies an otherwise blank, unformatted block. This is not present in this machine's install, or at least org/XeLaTeX don't know about it.
My steps were:
Search for all unnamed headings
Name each of them uniquely
Reproduce the error with the identifying string
Check the block type property against the available type list given in org-beamer-mode
Remove the offending type and replace it with another one
This is great and all, but I don't think it's the "best answer" because it involves no actual understanding of what the emacs interpreter was trying to tell me. If I didn't have a good idea of what was going on generally with the TeX, there's no way it would have worked. Dunno if this technique would impress anybody at an interview ;)
Recently, I often encounter errors like this:
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
I found that in some situations, the error is caused by expressions like this:
(= nil 4)
I'm not sure whether this expression is intended to write like this, but it will work only if I change it to:
(eq nil 4)
However, (1) I need to replace all = to eq in that emacs lisp script (2) I'm not sure the codes should be modified like this.
I was wondering that whether I can write a few lines in the config file (.emacs) instead of modify on the source code to get things done. Does anyone have ideas about this?
Don't do this.
You're going down the path of hiding errors in code. Figure out the root
cause of why you're passing nil to = and fix that.
From time to time I get a "nesting exceeds `max-lisp-eval-depth'" error.
What does it mean?
When I get one, is there something I can do, other than "killall emacs"?
Edit:
You can get the error if you evaluate:
(defun func ()
(func))
(func)
However, in this case emacs remains responsive.
An immediate remedy can be to simply increase the maximum. Its default value is 500, but you could set it to, say, 10000 like this:
(setq max-lisp-eval-depth 10000)
But that's generally not a great idea, because the fact that you run into a nesting exceeds `max-lisp-eval-depth' error in the first place is a sign that some part of your code is taking up too much stack space. But at least increasing the maximum temporarily can help you analyze the problem without getting the same error message over and over again.
Basically, it means that some Lisp code used up more stack than Emacs was compiled to permit.
In practice, it's a sign of a bug in Lisp code. Correctly written code should avoid nesting this deeply, even if the algorithm and the input data were "correct"; but more frequently, it happens because of an unhandled corner case or unexpected input.
In other words, you have probably created an endless loop via recusion, or perhaps e.g. a regular expression with exponential backtracking.
If you are lucky, repeated control-G keypresses could get you out of the conundrum without killing Emacs.
If you are developing Emacs Lisp code, you might want to tweak down the value of max-lisp-eval-depth artificially to help find spots where your code might need hardening or bug fixing. And of course, having debug-on-error set to t should help by showing you a backtrace of the stack.