X-Git-Url: https://git.hcoop.net/bpt/emacs.git/blobdiff_plain/51827f49030e5a2e30de304c23cab1be9c315f7c..0df333e5c914cd21820d87a8e4380af0ff28a926:/lispref/debugging.texi diff --git a/lispref/debugging.texi b/lispref/debugging.texi index 5886138eb5..854e0ef1ca 100644 --- a/lispref/debugging.texi +++ b/lispref/debugging.texi @@ -1,7 +1,7 @@ @c -*-texinfo-*- @c This is part of the GNU Emacs Lisp Reference Manual. -@c Copyright (C) 1990, 1991, 1992, 1993, 1994, 1998, 1999, 2005 -@c Free Software Foundation, Inc. +@c Copyright (C) 1990, 1991, 1992, 1993, 1994, 1998, 1999, 2002, 2003, 2004, +@c 2005, 2006 Free Software Foundation, Inc. @c See the file elisp.texi for copying conditions. @setfilename ../info/debugging @node Debugging, Read and Print, Advising Functions, Top @@ -118,8 +118,8 @@ the error. The easiest way is usually to set @end defopt @defopt eval-expression-debug-on-error -If you set this variable to a non-@code{nil} value, then -@code{debug-on-error} will be set to @code{t} when evaluating with the +If this variable has a non-@code{nil} value, then +@code{debug-on-error} is set to @code{t} when evaluating with the command @code{eval-expression}. If @code{eval-expression-debug-on-error} is @code{nil}, then the value of @code{debug-on-error} is not changed. @xref{Lisp Eval,, Evaluating @@ -166,20 +166,6 @@ this: (lambda () (setq debug-on-error t))) @end example -When the debugger is entered, it shows a backtrace (@pxref{Using -Debugger}). If you like to see the backtrace when an error happens, -but you do not want to enter the debugger, you can set the variable -@code{stack-trace-on-error} to non-@code{nil}. - -@defopt stack-trace-on-error -This variable determines whether a backtrace buffer is shown when an -error is signalled and not handled. If @code{stack-trace-on-error} is -@code{t}, all kinds of errors display a backtrace; if it is -@code{nil}, none do. If the value is a list, an error only means to -display a backtrace if one of its condition symbols appears in the -list. -@end defopt - @node Infinite Loops @subsection Debugging Infinite Loops @cindex infinite loops @@ -224,15 +210,19 @@ called shortly before the problem, step quickly over the call to that function, and then step through its caller. @deffn Command debug-on-entry function-name -This function requests @var{function-name} to invoke the debugger each time -it is called. It works by inserting the form @code{(debug 'debug)} into -the function definition as the first form. - -Any function defined as Lisp code may be set to break on entry, -regardless of whether it is interpreted code or compiled code. If the -function is a command, it will enter the debugger when called from Lisp -and when called interactively (after the reading of the arguments). You -can't debug primitive functions (i.e., those written in C) this way. +This function requests @var{function-name} to invoke the debugger each +time it is called. It works by inserting the form +@code{(implement-debug-on-entry)} into the function definition as the +first form. + +Any function or macro defined as Lisp code may be set to break on +entry, regardless of whether it is interpreted code or compiled code. +If the function is a command, it will enter the debugger when called +from Lisp and when called interactively (after the reading of the +arguments). You can also set debug-on-entry for primitive functions +(i.e., those written in C) this way, but it only takes effect when the +primitive is called from Lisp code. Debug-on-entry is not allowed for +special forms. When @code{debug-on-entry} is called interactively, it prompts for @var{function-name} in the minibuffer. If the function is already set @@ -281,16 +271,13 @@ Debugger entered--entering a function: @end example @end deffn -@deffn Command cancel-debug-on-entry function-name +@deffn Command cancel-debug-on-entry &optional function-name This function undoes the effect of @code{debug-on-entry} on @var{function-name}. When called interactively, it prompts for @var{function-name} in the minibuffer. If @var{function-name} is -@code{nil} or the empty string, it cancels break-on-entry for all -functions. - +omitted or @code{nil}, it cancels break-on-entry for all functions. Calling @code{cancel-debug-on-entry} does nothing to a function which is -not currently set up to break on entry. It always returns -@var{function-name}. +not currently set up to break on entry. @end deffn @node Explicit Debug @@ -363,7 +350,8 @@ structures of an interpreted function, but cannot do so in a byte-compiled function. If you would like to step through a byte-compiled function, replace it with an interpreted definition of the same function. (To do this, visit the source for the function and -type @kbd{C-M-x} on its definition.) +type @kbd{C-M-x} on its definition.) You cannot use the Lisp debugger +to step through a primitive function. Here is a list of Debugger mode commands: @@ -483,15 +471,15 @@ entered--entering a function:} as a line of text at the top of the buffer. @item debug -@code{debug} as first argument indicates a call to @code{debug} -because of entry to a function that was set to debug on entry. The -debugger displays @samp{Debugger entered--entering a function:}, just -as in the @code{lambda} case. It also marks the stack frame for that -function so that it will invoke the debugger when exited. +@code{debug} as first argument means @code{debug} was called because +of entry to a function that was set to debug on entry. The debugger +displays the string @samp{Debugger entered--entering a function:}, +just as in the @code{lambda} case. It also marks the stack frame for +that function so that it will invoke the debugger when exited. @item t When the first argument is @code{t}, this indicates a call to -@code{debug} due to evaluation of a list form when +@code{debug} due to evaluation of a function call form when @code{debug-on-next-call} is non-@code{nil}. The debugger displays @samp{Debugger entered--beginning evaluation of function call form:} as the top line in the buffer.