@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, 2008 Free Software Foundation, Inc.
+@c Copyright (C) 1990-1994, 1998-1999, 2001-2012 Free Software Foundation, Inc.
@c See the file elisp.texi for copying conditions.
@setfilename ../../info/debugging
@node Debugging, Read and Print, Advising Functions, Top
@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
the debugger gets out of the recursive edit and kills the backtrace
buffer.
+ When the debugger has been entered, the @code{debug-on-error}
+variable is temporarily set according to
+@code{eval-expression-debug-on-error}. If the latter variable is
+non-@code{nil}, @code{debug-on-error} will temporarily be set to
+@code{t}. This means that any further errors that occur while doing a
+debugging session will (by default) trigger another backtrace. If
+this is not want you want, you can either set
+@code{eval-expression-debug-on-error} to @code{nil}, or set
+@code{debug-on-error} to @code{nil} in @code{debugger-mode-hook}.
+
@cindex current stack frame
The backtrace buffer shows you the functions that are executing and
their argument values. It also allows you to specify a stack frame by
@end smallexample
@end deffn
-@ignore @c Not worth mentioning
-@defopt stack-trace-on-error
-@cindex stack trace
-This variable controls whether Lisp automatically displays a
-backtrace buffer after every error that is not handled. A quit signal
-counts as an error for this variable. If it is non-@code{nil} then a
-backtrace is shown in a pop-up buffer named @samp{*Backtrace*} on every
-error. If it is @code{nil}, then a backtrace is not shown.
-
-When a backtrace is shown, that buffer is not selected. If either
-@code{debug-on-quit} or @code{debug-on-error} is also non-@code{nil}, then
-a backtrace is shown in one buffer, and the debugger is popped up in
-another buffer with its own backtrace.
-
-We consider this feature to be obsolete and superseded by the debugger
-itself.
-@end defopt
-@end ignore
-
@defvar debug-on-next-call
@cindex @code{eval}, and debugging
@cindex @code{apply}, and debugging
successfully, then point is located at the end of the form. In this
case, this technique can't localize the error precisely, but can still
show you which function to check.
-
-@ignore
- arch-tag: ddc57378-b0e6-4195-b7b6-43f8777395a7
-@end ignore