@c -*-texinfo-*-
@c This is part of the GNU Emacs Lisp Reference Manual.
@c Copyright (C) 1990, 1991, 1992, 1993, 1994, 1998, 1999, 2001, 2002, 2003,
-@c 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
+@c 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
@c See the file elisp.texi for copying conditions.
-@setfilename ../info/debugging
+@setfilename ../../info/debugging
@node Debugging, Read and Print, Advising Functions, Top
@chapter Debugging Lisp Programs
@menu
* Debugger:: How the Emacs Lisp debugger is implemented.
-* Edebug:: A source-level Emacs Lisp debugger.
+* Edebug:: A source-level Emacs Lisp debugger.
* Syntax Errors:: How to find syntax errors.
* Test Coverage:: Ensuring you have tested all branches in your code.
* Compilation Errors:: How to find errors that show up in byte compilation.
@menu
* Error Debugging:: Entering the debugger when an error happens.
-* Infinite Loops:: Stopping and debugging a program that doesn't exit.
+* Infinite Loops:: Stopping and debugging a program that doesn't exit.
* Function Debugging:: Entering it when a certain function is called.
* Explicit Debug:: Entering it at a certain point in the program.
* Using Debugger:: What the debugger does; what you see while in it.
However, entry to the debugger is not a normal consequence of an
error. Many commands frequently cause Lisp errors when invoked
-inappropriately (such as @kbd{C-f} at the end of the buffer), and during
-ordinary editing it would be very inconvenient to enter the debugger
-each time this happens. So if you want errors to enter the debugger, set
-the variable @code{debug-on-error} to non-@code{nil}. (The command
+inappropriately, and during ordinary editing it would be very
+inconvenient to enter the debugger each time this happens. So if you
+want errors to enter the debugger, set the variable
+@code{debug-on-error} to non-@code{nil}. (The command
@code{toggle-debug-on-error} provides an easy way to do this.)
@defopt debug-on-error
-This variable determines whether the debugger is called when an error is
-signaled and not handled. If @code{debug-on-error} is @code{t}, all
-kinds of errors call the debugger (except those listed in
-@code{debug-ignored-errors}). If it is @code{nil}, none call the
-debugger.
+This variable determines whether the debugger is called when an error
+is signaled and not handled. If @code{debug-on-error} is @code{t},
+all kinds of errors call the debugger, except those listed in
+@code{debug-ignored-errors} (see below). If it is @code{nil}, none
+call the debugger. (Note that @code{eval-expression-debug-on-error}
+affects the setting of this variable in some cases; see below.)
The value can also be a list of error conditions that should call the
debugger. For example, if you set it to the list
bypasses the @code{condition-case} which normally catches errors in the
init file.
- If your init file sets @code{debug-on-error}, the effect may
-not last past the end of loading the init file. (This is an undesirable
-byproduct of the code that implements the @samp{--debug-init} command
-line option.) The best way to make the init file set
-@code{debug-on-error} permanently is with @code{after-init-hook}, like
-this:
-
-@example
-(add-hook 'after-init-hook
- (lambda () (setq debug-on-error t)))
-@end example
-
@node Infinite Loops
@subsection Debugging Infinite Loops
@cindex infinite loops