@comment -*-texinfo-*-@c This is part of the GNU Emacs Lisp Reference Manual.@c Copyright (C) 1992, 1993, 1994, 1998, 1999 Free Software Foundation, Inc. @c See the file elisp.texi for copying conditions.@c This file can also be used by an independent Edebug User @c Manual in which case the Edebug node below should be used @c with the following links to the Bugs section and to the top level:@c , Bugs and Todo List, Top, Top@node Edebug, Syntax Errors, Debugger, Debugging@section Edebug@cindex Edebug mode@cindex Edebug Edebug is a source-level debugger for Emacs Lisp programs with whichyou can:@itemize @bullet@itemStep through evaluation, stopping before and after each expression.@itemSet conditional or unconditional breakpoints.@itemStop when a specified condition is true (the global break event).@itemTrace slow or fast, stopping briefly at each stop point, orat each breakpoint.@itemDisplay expression results and evaluate expressions as if outside ofEdebug.@item Automatically re-evaluate a list of expressions anddisplay their results each time Edebug updates the display.@itemOutput trace info on function enter and exit.@itemStop when an error occurs.@itemDisplay a backtrace, omitting Edebug's own frames.@itemSpecify argument evaluation for macros and defining forms.@itemObtain rudimentary coverage testing and frequency counts.@end itemizeThe first three sections below should tell you enough about Edebug toenable you to use it.@menu* Using Edebug:: Introduction to use of Edebug.* Instrumenting:: You must instrument your code in order to debug it with Edebug.* Modes: Edebug Execution Modes. Execution modes, stopping more or less often.* Jumping:: Commands to jump to a specified place.* Misc: Edebug Misc. Miscellaneous commands.* Breakpoints:: Setting breakpoints to make the program stop.* Trapping Errors:: Trapping errors with Edebug.* Views: Edebug Views. Views inside and outside of Edebug.* Eval: Edebug Eval. Evaluating expressions within Edebug.* Eval List:: Expressions whose values are displayed each time you enter Edebug.* Printing in Edebug:: Customization of printing.* Trace Buffer:: How to produce trace output in a buffer.* Coverage Testing:: How to test evaluation coverage.* The Outside Context:: Data that Edebug saves and restores.* Instrumenting Macro Calls:: Specifying how to handle macro calls.* Options: Edebug Options. Option variables for customizing Edebug.@end menu@node Using Edebug@subsection Using Edebug To debug a Lisp program with Edebug, you must first @dfn{instrument}the Lisp code that you want to debug. A simple way to do this is tofirst move point into the definition of a function or macro and then do@kbd{C-u C-M-x} (@code{eval-defun} with a prefix argument). See@ref{Instrumenting}, for alternative ways to instrument code. Once a function is instrumented, any call to the function activatesEdebug. Depending on which Edebug execution mode you have selected,activating Edebug may stop execution and let you step through thefunction, or it may update the display and continue execution whilechecking for debugging commands. The default execution mode is step,which stops execution. @xref{Edebug Execution Modes}. Within Edebug, you normally view an Emacs buffer showing the source ofthe Lisp code you are debugging. This is referred to as the @dfn{sourcecode buffer}, and it is temporarily read-only. An arrow at the left margin indicates the line where the function isexecuting. Point initially shows where within the line the function isexecuting, but this ceases to be true if you move point yourself. If you instrument the definition of @code{fac} (shown below) and thenexecute @code{(fac 3)}, here is what you would normally see. Point isat the open-parenthesis before @code{if}.@example(defun fac (n)=>@point{}(if (< 0 n) (* n (fac (1- n))) 1))@end example@cindex stop pointsThe places within a function where Edebug can stop execution are called@dfn{stop points}. These occur both before and after each subexpressionthat is a list, and also after each variable reference. Here we use periods to show the stop points in the function@code{fac}:@example(defun fac (n) .(if .(< 0 n.). .(* n. .(fac (1- n.).).). 1).)@end exampleThe special commands of Edebug are available in the source code bufferin addition to the commands of Emacs Lisp mode. For example, you cantype the Edebug command @key{SPC} to execute until the next stop point.If you type @key{SPC} once after entry to @code{fac}, here is thedisplay you will see:@example(defun fac (n)=>(if @point{}(< 0 n) (* n (fac (1- n))) 1))@end exampleWhen Edebug stops execution after an expression, it displays theexpression's value in the echo area. Other frequently used commands are @kbd{b} to set a breakpoint at a stoppoint, @kbd{g} to execute until a breakpoint is reached, and @kbd{q} toexit Edebug and return to the top-level command loop. Type @kbd{?} todisplay a list of all Edebug commands.@node Instrumenting@subsection Instrumenting for Edebug In order to use Edebug to debug Lisp code, you must first@dfn{instrument} the code. Instrumenting code inserts additional codeinto it, to invoke Edebug at the proper places.@kindex C-M-x@findex eval-defun (Edebug) Once you have loaded Edebug, the command @kbd{C-M-x}(@code{eval-defun}) is redefined so that when invoked with a prefixargument on a definition, it instruments the definition beforeevaluating it. (The source code itself is not modified.) If thevariable @code{edebug-all-defs} is non-@code{nil}, that inverts themeaning of the prefix argument: in this case, @kbd{C-M-x} instruments thedefinition @emph{unless} it has a prefix argument. The default value of@code{edebug-all-defs} is @code{nil}. The command @kbd{M-xedebug-all-defs} toggles the value of the variable@code{edebug-all-defs}.@findex eval-region @r{(Edebug)}@findex eval-current-buffer @r{(Edebug)} If @code{edebug-all-defs} is non-@code{nil}, then the commands@code{eval-region}, @code{eval-current-buffer}, and @code{eval-buffer}also instrument any definitions they evaluate. Similarly,@code{edebug-all-forms} controls whether @code{eval-region} shouldinstrument @emph{any} form, even non-defining forms. This doesn't applyto loading or evaluations in the minibuffer. The command @kbd{M-xedebug-all-forms} toggles this option.@findex edebug-eval-top-level-form Another command, @kbd{M-x edebug-eval-top-level-form}, is available toinstrument any top-level form regardless of the values of@code{edebug-all-defs} and @code{edebug-all-forms}. While Edebug is active, the command @kbd{I}(@code{edebug-instrument-callee}) instruments the definition of thefunction or macro called by the list form after point, if is not alreadyinstrumented. This is possible only if Edebug knows where to find thesource for that function; for this reading, after loading Edebug,@code{eval-region} records the position of every definition itevaluates, even if not instrumenting it. See also the @kbd{i} command(@pxref{Jumping}), which steps into the call after instrumenting thefunction.@cindex special forms (Edebug)@cindex interactive commands (Edebug)@cindex anonymous lambda expressions (Edebug)@cindex Common Lisp (Edebug)@pindex cl.el @r{(Edebug)}@pindex cl-specs.el Edebug knows how to instrument all the standard special forms,@code{interactive} forms with an expression argument, anonymous lambdaexpressions, and other defining forms. However, Edebug cannot determineon its own what a user-defined macro will do with the arguments of amacro call, so you must provide that information; see @ref{InstrumentingMacro Calls}, for details. When Edebug is about to instrument code for the first time in asession, it runs the hook @code{edebug-setup-hook}, then sets it to@code{nil}. You can use this to load Edebug specifications(@pxref{Instrumenting Macro Calls}) associated with a package you areusing, but only when you use Edebug.@findex eval-expression @r{(Edebug)} To remove instrumentation from a definition, simply re-evaluate itsdefinition in a way that does not instrument. There are two ways ofevaluating forms that never instrument them: from a file with@code{load}, and from the minibuffer with @code{eval-expression}(@kbd{M-:}). If Edebug detects a syntax error while instrumenting, it leaves pointat the erroneous code and signals an @code{invalid-read-syntax} error. @xref{Edebug Eval}, for other evaluation functions availableinside of Edebug.@node Edebug Execution Modes@subsection Edebug Execution Modes@cindex Edebug execution modesEdebug supports several execution modes for running the program you aredebugging. We call these alternatives @dfn{Edebug execution modes}; donot confuse them with major or minor modes. The current Edebug execution modedetermines how far Edebug continues execution before stopping---whetherit stops at each stop point, or continues to the next breakpoint, forexample---and how much Edebug displays the progress of the evaluationbefore it stops.Normally, you specify the Edebug execution mode by typing a command tocontinue the program in a certain mode. Here is a table of thesecommands; all except for @kbd{S} resume execution of the program, atleast for a certain distance.@table @kbd@item SStop: don't execute any more of the program, but wait for moreEdebug commands (@code{edebug-stop}).@item @key{SPC}Step: stop at the next stop point encountered (@code{edebug-step-mode}).@item nNext: stop at the next stop point encountered after an expression(@code{edebug-next-mode}). Also see @code{edebug-forward-sexp} in@ref{Edebug Misc}.@item tTrace: pause one second at each Edebug stop point (@code{edebug-trace-mode}).@item TRapid trace: update the display at each stop point, but don't actuallypause (@code{edebug-Trace-fast-mode}).@item gGo: run until the next breakpoint (@code{edebug-go-mode}). @xref{Breakpoints}.@item cContinue: pause one second at each breakpoint, and then continue(@code{edebug-continue-mode}).@item CRapid continue: move point to each breakpoint, but don't pause(@code{edebug-Continue-fast-mode}).@item GGo non-stop: ignore breakpoints (@code{edebug-Go-nonstop-mode}). Youcan still stop the program by typing @kbd{S}, or any editing command.@end tableIn general, the execution modes earlier in the above list run theprogram more slowly or stop sooner than the modes later in the list.While executing or tracing, you can interrupt the execution by typingany Edebug command. Edebug stops the program at the next stop point andthen executes the command you typed. For example, typing @kbd{t} duringexecution switches to trace mode at the next stop point. You can use@kbd{S} to stop execution without doing anything else.If your function happens to read input, a character you type intendingto interrupt execution may be read by the function instead. You canavoid such unintended results by paying attention to when your programwants input.@cindex keyboard macros (Edebug)Keyboard macros containing the commands in this section do notcompletely work: exiting from Edebug, to resume the program, loses trackof the keyboard macro. This is not easy to fix. Also, defining orexecuting a keyboard macro outside of Edebug does not affect commandsinside Edebug. This is usually an advantage. See also the@code{edebug-continue-kbd-macro} option (@pxref{Edebug Options}).When you enter a new Edebug level, the initial execution mode comes fromthe value of the variable @code{edebug-initial-mode}. By default, thisspecifies step mode. Note that you may reenter the same Edebug levelseveral times if, for example, an instrumented function is calledseveral times from one command.@node Jumping@subsection Jumping The commands described in this section execute until they reach aspecified location. All except @kbd{i} make a temporary breakpoint toestablish the place to stop, then switch to go mode. Any otherbreakpoint reached before the intended stop point will also stopexecution. @xref{Breakpoints}, for the details on breakpoints. These commands may fail to work as expected in case of nonlocal exit,as that can bypass the temporary breakpoint where you expected theprogram to stop.@table @kbd@item hProceed to the stop point near where point is (@code{edebug-goto-here}).@item fRun the program forward over one expression(@code{edebug-forward-sexp}).@item oRun the program until the end of the containing sexp.@item iStep into the function or macro called by the form after point.@end tableThe @kbd{h} command proceeds to the stop point near the current locationof point, using a temporary breakpoint. See @ref{Breakpoints}, for moreinformation about breakpoints.The @kbd{f} command runs the program forward over one expression. Moreprecisely, it sets a temporary breakpoint at the position that@kbd{C-M-f} would reach, then executes in go mode so that the programwill stop at breakpoints.With a prefix argument @var{n}, the temporary breakpoint is placed@var{n} sexps beyond point. If the containing list ends before @var{n}more elements, then the place to stop is after the containingexpression.You must check that the position @kbd{C-M-f} finds is a place that theprogram will really get to. In @code{cond}, for example, this may notbe true.For flexibility, the @kbd{f} command does @code{forward-sexp} startingat point, rather than at the stop point. If you want to execute oneexpression @emph{from the current stop point}, first type @kbd{w}, tomove point there, and then type @kbd{f}.The @kbd{o} command continues ``out of'' an expression. It places atemporary breakpoint at the end of the sexp containing point. If thecontaining sexp is a function definition itself, @kbd{o} continues untiljust before the last sexp in the definition. If that is where you arenow, it returns from the function and then stops. In other words, thiscommand does not exit the currently executing function unless you arepositioned after the last sexp.The @kbd{i} command steps into the function or macro called by the listform after point, and stops at its first stop point. Note that the formneed not be the one about to be evaluated. But if the form is afunction call about to be evaluated, remember to use this command beforeany of the arguments are evaluated, since otherwise it will be too late.The @kbd{i} command instruments the function or macro it's supposed tostep into, if it isn't instrumented already. This is convenient, but keepin mind that the function or macro remains instrumented unless you explicitlyarrange to deinstrument it.@node Edebug Misc@subsection Miscellaneous Edebug Commands Some miscellaneous Edebug commands are described here.@table @kbd@item ?Display the help message for Edebug (@code{edebug-help}).@item C-]Abort one level back to the previous command level(@code{abort-recursive-edit}).@item qReturn to the top level editor command loop (@code{top-level}). Thisexits all recursive editing levels, including all levels of Edebugactivity. However, instrumented code protected with@code{unwind-protect} or @code{condition-case} forms may resumedebugging.@item QLike @kbd{q}, but don't stop even for protected code(@code{top-level-nonstop}).@item rRedisplay the most recently known expression result in the echo area(@code{edebug-previous-result}).@item dDisplay a backtrace, excluding Edebug's own functions for clarity(@code{edebug-backtrace}).You cannot use debugger commands in the backtrace buffer in Edebug asyou would in the standard debugger.The backtrace buffer is killed automatically when you continueexecution.@end tableYou can invoke commands from Edebug that activate Edebug againrecursively. Whenever Edebug is active, you can quit to the top levelwith @kbd{q} or abort one recursive edit level with @kbd{C-]}. You candisplay a backtrace of all the pending evaluations with @kbd{d}.@node Breakpoints@subsection Breakpoints@cindex breakpointsEdebug's step mode stops execution when the next stop point is reached.There are three other ways to stop Edebug execution once it has started:breakpoints, the global break condition, and source breakpoints.While using Edebug, you can specify @dfn{breakpoints} in the program youare testing: these are places where execution should stop. You can set abreakpoint at any stop point, as defined in @ref{Using Edebug}. Forsetting and unsetting breakpoints, the stop point that is affected isthe first one at or after point in the source code buffer. Here are theEdebug commands for breakpoints:@table @kbd@item bSet a breakpoint at the stop point at or after point(@code{edebug-set-breakpoint}). If you use a prefix argument, thebreakpoint is temporary---it turns off the first time it stops theprogram.@item uUnset the breakpoint (if any) at the stop point at or after point (@code{edebug-unset-breakpoint}).@item x @var{condition} @key{RET}Set a conditional breakpoint which stops the program only if@var{condition} evaluates to a non-@code{nil} value(@code{edebug-set-conditional-breakpoint}). With a prefix argument, thebreakpoint is temporary.@item BMove point to the next breakpoint in the current definition(@code{edebug-next-breakpoint}).@end tableWhile in Edebug, you can set a breakpoint with @kbd{b} and unset onewith @kbd{u}. First move point to the Edebug stop point of your choice,then type @kbd{b} or @kbd{u} to set or unset a breakpoint there.Unsetting a breakpoint where none has been set has no effect.Re-evaluating or reinstrumenting a definition removes all of itsprevious breakpoints.A @dfn{conditional breakpoint} tests a condition each time the programgets there. Any errors that occur as a result of evaluating thecondition are ignored, as if the result were @code{nil}. To set aconditional breakpoint, use @kbd{x}, and specify the conditionexpression in the minibuffer. Setting a conditional breakpoint at astop point that has a previously established conditional breakpoint putsthe previous condition expression in the minibuffer so you can edit it.You can make a conditional or unconditional breakpoint@dfn{temporary} by using a prefix argument with the command to set thebreakpoint. When a temporary breakpoint stops the program, it isautomatically unset.Edebug always stops or pauses at a breakpoint, except when the Edebugmode is Go-nonstop. In that mode, it ignores breakpoints entirely.To find out where your breakpoints are, use the @kbd{B} command, whichmoves point to the next breakpoint following point, within the samefunction, or to the first breakpoint if there are no followingbreakpoints. This command does not continue execution---it just movespoint in the buffer.@menu* Global Break Condition:: Breaking on an event. * Source Breakpoints:: Embedding breakpoints in source code.@end menu@node Global Break Condition@subsubsection Global Break Condition@cindex stopping on events@cindex global break condition A @dfn{global break condition} stops execution when a specifiedcondition is satisfied, no matter where that may occur. Edebugevaluates the global break condition at every stop point; if itevaluates to a non-@code{nil} value, then execution stops or pausesdepending on the execution mode, as if a breakpoint had been hit. Ifevaluating the condition gets an error, execution does not stop.@findex edebug-set-global-break-condition The condition expression is stored in@code{edebug-global-break-condition}. You can specify a new expressionusing the @kbd{X} command (@code{edebug-set-global-break-condition}). The global break condition is the simplest way to find where in yourcode some event occurs, but it makes code run much more slowly. So youshould reset the condition to @code{nil} when not using it.@node Source Breakpoints@subsubsection Source Breakpoints@findex edebug@cindex source breakpoints All breakpoints in a definition are forgotten each time youreinstrument it. If you wish to make a breakpoint that won't beforgotten, you can write a @dfn{source breakpoint}, which is simply acall to the function @code{edebug} in your source code. You can, ofcourse, make such a call conditional. For example, in the @code{fac}function, you can insert the first line as shown below, to stop when theargument reaches zero:@example(defun fac (n) (if (= n 0) (edebug)) (if (< 0 n) (* n (fac (1- n))) 1))@end example When the @code{fac} definition is instrumented and the function iscalled, the call to @code{edebug} acts as a breakpoint. Depending onthe execution mode, Edebug stops or pauses there. If no instrumented code is being executed when @code{edebug} is called,that function calls @code{debug}.@c This may not be a good idea anymore.@node Trapping Errors@subsection Trapping Errors Emacs normally displays an error message when an error is signaled andnot handled with @code{condition-case}. While Edebug is active andexecuting instrumented code, it normally responds to all unhandlederrors. You can customize this with the options @code{edebug-on-error}and @code{edebug-on-quit}; see @ref{Edebug Options}. When Edebug responds to an error, it shows the last stop pointencountered before the error. This may be the location of a call to afunction which was not instrumented, and within which the error actuallyoccurred. For an unbound variable error, the last known stop pointmight be quite distant from the offending variable reference. In thatcase, you might want to display a full backtrace (@pxref{Edebug Misc}).@c Edebug should be changed for the following: -- dan If you change @code{debug-on-error} or @code{debug-on-quit} whileEdebug is active, these changes will be forgotten when Edebug becomesinactive. Furthermore, during Edebug's recursive edit, these variablesare bound to the values they had outside of Edebug.@node Edebug Views@subsection Edebug Views These Edebug commands let you view aspects of the buffer and windowstatus as they were before entry to Edebug. The outside windowconfiguration is the collection of windows and contents that were ineffect outside of Edebug.@table @kbd@item vTemporarily view the outside window configuration(@code{edebug-view-outside}).@item pTemporarily display the outside current buffer with point at its outsideposition (@code{edebug-bounce-point}). With a prefix argument @var{n},pause for @var{n} seconds instead.@item wMove point back to the current stop point in the source code buffer(@code{edebug-where}).If you use this command in a different window displaying the samebuffer, that window will be used instead to display the currentdefinition in the future.@item W@c Its function is not simply to forget the saved configuration -- danToggle whether Edebug saves and restores the outside windowconfiguration (@code{edebug-toggle-save-windows}).With a prefix argument, @code{W} only toggles saving and restoring ofthe selected window. To specify a window that is not displaying thesource code buffer, you must use @kbd{C-x X W} from the global keymap.@end table You can view the outside window configuration with @kbd{v} or justbounce to the point in the current buffer with @kbd{p}, even ifit is not normally displayed. After moving point, you may wish to jumpback to the stop point with @kbd{w} from a source code buffer. Each time you use @kbd{W} to turn saving @emph{off}, Edebug forgets thesaved outside window configuration---so that even if you turn savingback @emph{on}, the current window configuration remains unchanged whenyou next exit Edebug (by continuing the program). However, theautomatic redisplay of @samp{*edebug*} and @samp{*edebug-trace*} mayconflict with the buffers you wish to see unless you have enough windowsopen.@node Edebug Eval@subsection Evaluation While within Edebug, you can evaluate expressions ``as if'' Edebugwere not running. Edebug tries to be invisible to the expression'sevaluation and printing. Evaluation of expressions that cause sideeffects will work as expected, except for changes to data that Edebugexplicitly saves and restores. @xref{The Outside Context}, for detailson this process.@table @kbd@item e @var{exp} @key{RET}Evaluate expression @var{exp} in the context outside of Edebug(@code{edebug-eval-expression}). That is, Edebug tries to minimize itsinterference with the evaluation.@item M-: @var{exp} @key{RET}Evaluate expression @var{exp} in the context of Edebug itself.@item C-x C-eEvaluate the expression before point, in the context outside of Edebug(@code{edebug-eval-last-sexp}).@end table@cindex lexical binding (Edebug) Edebug supports evaluation of expressions containing references tolexically bound symbols created by the following constructs in@file{cl.el} (version 2.03 or later): @code{lexical-let},@code{macrolet}, and @code{symbol-macrolet}.@node Eval List@subsection Evaluation List Buffer You can use the @dfn{evaluation list buffer}, called @samp{*edebug*}, toevaluate expressions interactively. You can also set up the@dfn{evaluation list} of expressions to be evaluated automatically eachtime Edebug updates the display.@table @kbd@item ESwitch to the evaluation list buffer @samp{*edebug*}(@code{edebug-visit-eval-list}).@end table In the @samp{*edebug*} buffer you can use the commands of LispInteraction mode (@pxref{Lisp Interaction,,, emacs, The GNU EmacsManual}) as well as these special commands:@table @kbd@item C-jEvaluate the expression before point, in the outside context, and insertthe value in the buffer (@code{edebug-eval-print-last-sexp}).@item C-x C-eEvaluate the expression before point, in the context outside of Edebug(@code{edebug-eval-last-sexp}).@item C-c C-uBuild a new evaluation list from the contents of the buffer(@code{edebug-update-eval-list}).@item C-c C-dDelete the evaluation list group that point is in(@code{edebug-delete-eval-item}).@item C-c C-wSwitch back to the source code buffer at the current stop point(@code{edebug-where}).@end table You can evaluate expressions in the evaluation list window with@kbd{C-j} or @kbd{C-x C-e}, just as you would in @samp{*scratch*};but they are evaluated in the context outside of Edebug. The expressions you enter interactively (and their results) are lostwhen you continue execution; but you can set up an @dfn{evaluation list}consisting of expressions to be evaluated each time execution stops. @cindex evaluation list group To do this, write one or more @dfn{evaluation list groups} in theevaluation list buffer. An evaluation list group consists of one ormore Lisp expressions. Groups are separated by comment lines. The command @kbd{C-c C-u} (@code{edebug-update-eval-list}) rebuilds theevaluation list, scanning the buffer and using the first expression ofeach group. (The idea is that the second expression of the group is thevalue previously computed and displayed.) Each entry to Edebug redisplays the evaluation list by inserting eachexpression in the buffer, followed by its current value. It alsoinserts comment lines so that each expression becomes its own group.Thus, if you type @kbd{C-c C-u} again without changing the buffer text,the evaluation list is effectively unchanged. If an error occurs during an evaluation from the evaluation list, theerror message is displayed in a string as if it were the result.Therefore, expressions that use variables not currently valid do notinterrupt your debugging. Here is an example of what the evaluation list window looks like afterseveral expressions have been added to it:@smallexample(current-buffer)#<buffer *scratch*>;---------------------------------------------------------------(selected-window)#<window 16 on *scratch*>;---------------------------------------------------------------(point)196;---------------------------------------------------------------bad-var"Symbol's value as variable is void: bad-var";---------------------------------------------------------------(recursion-depth)0;---------------------------------------------------------------this-commandeval-last-sexp;---------------------------------------------------------------@end smallexampleTo delete a group, move point into it and type @kbd{C-c C-d}, or simplydelete the text for the group and update the evaluation list with@kbd{C-c C-u}. To add a new expression to the evaluation list, insertthe expression at a suitable place, insert a new comment line, then type@kbd{C-c C-u}. You need not insert dashes in the comment line---itscontents don't matter.After selecting @samp{*edebug*}, you can return to the source codebuffer with @kbd{C-c C-w}. The @samp{*edebug*} buffer is killed whenyou continue execution, and recreated next time it is needed.@node Printing in Edebug@subsection Printing in Edebug@cindex printing (Edebug)@cindex printing circular structures@pindex cust-print If an expression in your program produces a value containing circularlist structure, you may get an error when Edebug attempts to print it. One way to cope with circular structure is to set @code{print-length}or @code{print-level} to truncate the printing. Edebug does this foryou; it binds @code{print-length} and @code{print-level} to 50 if theywere @code{nil}. (Actually, the variables @code{edebug-print-length}and @code{edebug-print-level} specify the values to use within Edebug.)@xref{Output Variables}.@defopt edebug-print-lengthIf non-@code{nil}, Edebug binds @code{print-length} to this value whileprinting results. The default value is @code{50}.@end defopt@defopt edebug-print-level If non-@code{nil}, Edebug binds @code{print-level} to this value whileprinting results. The default value is @code{50}.@end defopt You can also print circular structures and structures that shareelements more informatively by binding @code{print-circle}to a non-@code{nil} value. Here is an example of code that creates a circular structure:@example(setq a '(x y))(setcar a a)@end example@noindentCustom printing prints this as @samp{Result: #1=(#1# y)}. The@samp{#1=} notation labels the structure that follows it with the label@samp{1}, and the @samp{#1#} notation references the previously labeledstructure. This notation is used for any shared elements of lists orvectors.@defopt edebug-print-circle If non-@code{nil}, Edebug binds @code{print-circle} to this value whileprinting results. The default value is @code{nil}.@end defopt Other programs can also use custom printing; see @file{cust-print.el}for details.@node Trace Buffer@subsection Trace Buffer@cindex trace buffer Edebug can record an execution trace, storing it in a buffer named@samp{*edebug-trace*}. This is a log of function calls and returns,showing the function names and their arguments and values. To enabletrace recording, set @code{edebug-trace} to a non-@code{nil} value. Making a trace buffer is not the same thing as using trace executionmode (@pxref{Edebug Execution Modes}). When trace recording is enabled, each function entry and exit addslines to the trace buffer. A function entry record consists of@samp{::::@{}, followed by the function name and argument values. Afunction exit record consists of @samp{::::@}}, followed by the functionname and result of the function. The number of @samp{:}s in an entry shows its recursion depth. Youcan use the braces in the trace buffer to find the matching beginning orend of function calls.@findex edebug-print-trace-before@findex edebug-print-trace-after You can customize trace recording for function entry and exit byredefining the functions @code{edebug-print-trace-before} and@code{edebug-print-trace-after}.@defmac edebug-tracing string body@dots{}This macro requests additional trace information around the executionof the @var{body} forms. The argument @var{string} specifies textto put in the trace buffer. All the arguments are evaluated, and@code{edebug-tracing} returns the value of the last form in @var{body}.@end defmac@defun edebug-trace format-string &rest format-argsThis function inserts text in the trace buffer. It computes the textwith @code{(apply 'format @var{format-string} @var{format-args})}.It also appends a newline to separate entries.@end defun @code{edebug-tracing} and @code{edebug-trace} insert lines in thetrace buffer whenever they are called, even if Edebug is not active.Adding text to the trace buffer also scrolls its window to show the lastlines inserted.@node Coverage Testing@subsection Coverage Testing@cindex coverage testing@cindex frequency counts@cindex performance analysisEdebug provides rudimentary coverage testing and display of executionfrequency. Coverage testing works by comparing the result of each expression withthe previous result; each form in the program is considered ``covered''if it has returned two different values since you began testing coveragein the current Emacs session. Thus, to do coverage testing on yourprogram, execute it under various conditions and note whether it behavescorrectly; Edebug will tell you when you have tried enough differentconditions that each form has returned two different values. Coverage testing makes execution slower, so it is only done if@code{edebug-test-coverage} is non-@code{nil}. Frequency counting isperformed for all execution of an instrumented function, even if theexecution mode is Go-nonstop, and regardless of whether coverage testingis enabled. Use @kbd{M-x edebug-display-freq-count} to display both thecoverage information and the frequency counts for a definition.@deffn Command edebug-display-freq-countThis command displays the frequency count data for each line of thecurrent definition.The frequency counts appear as comment lines after each line of code,and you can undo all insertions with one @code{undo} command. Thecounts appear under the @samp{(} before an expression or the @samp{)}after an expression, or on the last character of a variable. Tosimplify the display, a count is not shown if it is equal to thecount of an earlier expression on the same line.The character @samp{=} following the count for an expression says thatthe expression has returned the same value each time it was evaluated.In other words, it is not yet ``covered'' for coverage testing purposes.To clear the frequency count and coverage data for a definition,simply reinstrument it with @code{eval-defun}.@end deffnFor example, after evaluating @code{(fac 5)} with a sourcebreakpoint, and setting @code{edebug-test-coverage} to @code{t}, whenthe breakpoint is reached, the frequency data looks like this:@example(defun fac (n) (if (= n 0) (edebug));#6 1 0 =5 (if (< 0 n);#5 = (* n (fac (1- n)));# 5 0 1));# 0 @end exampleThe comment lines show that @code{fac} was called 6 times. Thefirst @code{if} statement returned 5 times with the same result eachtime; the same is true of the condition on the second @code{if}.The recursive call of @code{fac} did not return at all.@node The Outside Context@subsection The Outside ContextEdebug tries to be transparent to the program you are debugging, but itdoes not succeed completely. Edebug also tries to be transparent whenyou evaluate expressions with @kbd{e} or with the evaluation listbuffer, by temporarily restoring the outside context. This sectionexplains precisely what context Edebug restores, and how Edebug fails tobe completely transparent.@menu* Checking Whether to Stop:: When Edebug decides what to do.* Edebug Display Update:: When Edebug updates the display.* Edebug Recursive Edit:: When Edebug stops execution.@end menu@node Checking Whether to Stop@subsubsection Checking Whether to StopWhenever Edebug is entered, it needs to save and restore certain databefore even deciding whether to make trace information or stop theprogram.@itemize @bullet@item @code{max-lisp-eval-depth} and @code{max-specpdl-size} are bothincremented once to reduce Edebug's impact on the stack. You could,however, still run out of stack space when using Edebug.@item The state of keyboard macro execution is saved and restored. WhileEdebug is active, @code{executing-macro} is bound to@code{edebug-continue-kbd-macro}.@end itemize@node Edebug Display Update@subsubsection Edebug Display Update@c This paragraph is not filled, because LaLiberte's conversion script@c needs an xref to be on just one line.When Edebug needs to display something (e.g., in trace mode), it savesthe current window configuration from ``outside'' Edebug (@pxref{Window Configurations}). When you exit Edebug (by continuingthe program), it restores the previous window configuration.Emacs redisplays only when it pauses. Usually, when you continueexecution, the program re-enters Edebug at a breakpoint or afterstepping, without pausing or reading input in between. In such cases,Emacs never gets a chance to redisplay the ``outside'' configuration.Consequently, what you see is the same window configuration as the lasttime Edebug was active, with no interruption.Entry to Edebug for displaying something also saves and restores thefollowing data (though some of them are deliberately not restored if anerror or quit signal occurs).@itemize @bullet@item @cindex current buffer point and mark (Edebug)Which buffer is current, and the positions of point and the mark in thecurrent buffer, are saved and restored.@item @cindex window configuration (Edebug)The outside window configuration is saved and restored if@code{edebug-save-windows} is non-@code{nil} (@pxref{Edebug Display Update}).The window configuration is not restored on error or quit, but theoutside selected window @emph{is} reselected even on error or quit incase a @code{save-excursion} is active. If the value of@code{edebug-save-windows} is a list, only the listed windows are savedand restored.The window start and horizontal scrolling of the source code buffer arenot restored, however, so that the display remains coherent within Edebug.@itemThe value of point in each displayed buffer is saved and restored if@code{edebug-save-displayed-buffer-points} is non-@code{nil}.@itemThe variables @code{overlay-arrow-position} and@code{overlay-arrow-string} are saved and restored. So you can safelyinvoke Edebug from the recursive edit elsewhere in the same buffer.@item @code{cursor-in-echo-area} is locally bound to @code{nil} so thatthe cursor shows up in the window.@end itemize@node Edebug Recursive Edit@subsubsection Edebug Recursive EditWhen Edebug is entered and actually reads commands from the user, itsaves (and later restores) these additional data:@itemize @bullet@itemThe current match data. @xref{Match Data}.@item@code{last-command}, @code{this-command}, @code{last-command-char},@code{last-input-char}, @code{last-input-event},@code{last-command-event}, @code{last-event-frame},@code{last-nonmenu-event}, and @code{track-mouse}. Commands used withinEdebug do not affect these variables outside of Edebug.The key sequence returned by @code{this-command-keys} is changed byexecuting commands within Edebug and there is no way to resetthe key sequence from Lisp.Edebug cannot save and restore the value of@code{unread-command-events}. Entering Edebug while this variable has anontrivial value can interfere with execution of the program you aredebugging.@itemComplex commands executed while in Edebug are added to the variable@code{command-history}. In rare cases this can alter execution.@itemWithin Edebug, the recursion depth appears one deeper than the recursiondepth outside Edebug. This is not true of the automatically updatedevaluation list window.@item@code{standard-output} and @code{standard-input} are bound to @code{nil}by the @code{recursive-edit}, but Edebug temporarily restores them duringevaluations.@item The state of keyboard macro definition is saved and restored. WhileEdebug is active, @code{defining-kbd-macro} is bound to@code{edebug-continue-kbd-macro}.@end itemize@node Instrumenting Macro Calls@subsection Instrumenting Macro Calls When Edebug instruments an expression that calls a Lisp macro, it needsadditional information about the macro to do the job properly. This isbecause there is no a-priori way to tell which subexpressions of themacro call are forms to be evaluated. (Evaluation may occur explicitlyin the macro body, or when the resulting expansion is evaluated, or anytime later.) Therefore, you must define an Edebug specification for each macrothat Edebug will encounter, to explain the format of calls to thatmacro. To do this, add an @code{edebug} declaration to the macrodefinition. Here is a simple example that shows the specification forthe @code{for} example macro (@pxref{Argument Evaluation}).@example(defmacro for (var from init to final do &rest body) "Execute a simple \"for\" loop.For example, (for i from 1 to 10 do (print i))." (declare (edebug symbolp "from" form "to" form "do" &rest form)) ...)@end example@defspec declare (edebug @var{specification})Specify which expressions of a call to the macro in which thedeclaration appears are forms to be evaluated. For simple macros, the@var{specification} often looks very similar to the formal argument listof the macro definition, but specifications are much more general thanmacro arguments.@end defspecYou can also define an edebug specification for a macro separatelyfrom the macro definition with @code{def-edebug-spec}. Adding@code{edebug} declarations is preferred, and more convenient, formacro definitions in Lisp, but @code{def-edebug-spec} makes itpossible to define Edebug specifications for special forms implementedin C.@deffn Macro def-edebug-spec macro specificationSpecify which expressions of a call to macro @var{macro} are forms to beevaluated. @var{specification} should be the edebug specification.It is not evaluated.The @var{macro} argument can actually be any symbol, not just a macroname.@end deffnHere is a table of the possibilities for @var{specification} and how eachdirects processing of arguments.@table @asis@item @code{t}All arguments are instrumented for evaluation.@item @code{0}None of the arguments is instrumented.@item a symbolThe symbol must have an Edebug specification which is used instead.This indirection is repeated until another kind of specification isfound. This allows you to inherit the specification from another macro.@item a listThe elements of the list describe the types of the arguments of acalling form. The possible elements of a specification list aredescribed in the following sections.@end table@menu* Specification List:: How to specify complex patterns of evaluation.* Backtracking:: What Edebug does when matching fails.* Specification Examples:: To help understand specifications.@end menu@node Specification List@subsubsection Specification List@cindex Edebug specification listA @dfn{specification list} is required for an Edebug specification ifsome arguments of a macro call are evaluated while others are not. Someelements in a specification list match one or more arguments, but othersmodify the processing of all following elements. The latter, called@dfn{specification keywords}, are symbols beginning with @samp{&} (suchas @code{&optional}).A specification list may contain sublists which match arguments that arethemselves lists, or it may contain vectors used for grouping. Sublistsand groups thus subdivide the specification list into a hierarchy oflevels. Specification keywords apply only to the remainder of thesublist or group they are contained in.When a specification list involves alternatives or repetition, matchingit against an actual macro call may require backtracking.@xref{Backtracking}, for more details.Edebug specifications provide the power of regular expression matching,plus some context-free grammar constructs: the matching of sublists withbalanced parentheses, recursive processing of forms, and recursion viaindirect specifications.Here's a table of the possible elements of a specification list, withtheir meanings:@table @code@item sexpA single unevaluated Lisp object, which is not instrumented.@c an "expression" is not necessarily intended for evaluation.@item formA single evaluated expression, which is instrumented.@item place@findex edebug-unwrapA place to store a value, as in the Common Lisp @code{setf} construct.@item bodyShort for @code{&rest form}. See @code{&rest} below.@item function-formA function form: either a quoted function symbol, a quoted lambdaexpression, or a form (that should evaluate to a function symbol orlambda expression). This is useful when an argument that's a lambdaexpression might be quoted with @code{quote} rather than@code{function}, since it instruments the body of the lambda expressioneither way.@item lambda-exprA lambda expression with no quoting.@item &optional@kindex &optional @r{(Edebug)}All following elements in the specification list are optional; as soonas one does not match, Edebug stops matching at this level. To make just a few elements optional followed by non-optional elements,use @code{[&optional @var{specs}@dots{}]}. To specify that severalelements must all match or none, use @code{&optional[@var{specs}@dots{}]}. See the @code{defun} example below.@item &rest@kindex &rest @r{(Edebug)}All following elements in the specification list are repeated zero ormore times. In the last repetition, however, it is not a problem if theexpression runs out before matching all of the elements of thespecification list.To repeat only a few elements, use @code{[&rest @var{specs}@dots{}]}.To specify several elements that must all match on every repetition, use@code{&rest [@var{specs}@dots{}]}.@item &or@kindex &or @r{(Edebug)}Each of the following elements in the specification list is analternative. One of the alternatives must match, or the @code{&or}specification fails.Each list element following @code{&or} is a single alternative. Togroup two or more list elements as a single alternative, enclose them in@code{[@dots{}]}.@item ¬@kindex ¬ @r{(Edebug)}Each of the following elements is matched as alternatives as if by using@code{&or}, but if any of them match, the specification fails. If noneof them match, nothing is matched, but the @code{¬} specificationsucceeds.@item &define @kindex &define @r{(Edebug)}Indicates that the specification is for a defining form. The definingform itself is not instrumented (that is, Edebug does not stop before andafter the defining form), but forms inside it typically will beinstrumented. The @code{&define} keyword should be the first element ina list specification.@item nilThis is successful when there are no more arguments to match at thecurrent argument list level; otherwise it fails. See sublistspecifications and the backquote example below.@item gate@cindex preventing backtrackingNo argument is matched but backtracking through the gate is disabledwhile matching the remainder of the specifications at this level. Thisis primarily used to generate more specific syntax error messages. See@ref{Backtracking}, for more details. Also see the @code{let} examplebelow.@item @var{other-symbol}@cindex indirect specificationsAny other symbol in a specification list may be a predicate or anindirect specification.If the symbol has an Edebug specification, this @dfn{indirectspecification} should be either a list specification that is used inplace of the symbol, or a function that is called to process thearguments. The specification may be defined with @code{def-edebug-spec}just as for macros. See the @code{defun} example below.Otherwise, the symbol should be a predicate. The predicate is calledwith the argument and the specification fails if the predicate returns@code{nil}. In either case, that argument is not instrumented.Some suitable predicates include @code{symbolp}, @code{integerp},@code{stringp}, @code{vectorp}, and @code{atom}.@item [@var{elements}@dots{}]@cindex [@dots{}] (Edebug)A vector of elements groups the elements into a single @dfn{groupspecification}. Its meaning has nothing to do with vectors.@item "@var{string}"The argument should be a symbol named @var{string}. This specificationis equivalent to the quoted symbol, @code{'@var{symbol}}, where the nameof @var{symbol} is the @var{string}, but the string form is preferred.@item (vector @var{elements}@dots{})The argument should be a vector whose elements must match the@var{elements} in the specification. See the backquote example below.@item (@var{elements}@dots{})Any other list is a @dfn{sublist specification} and the argument must bea list whose elements match the specification @var{elements}.@cindex dotted lists (Edebug)A sublist specification may be a dotted list and the corresponding listargument may then be a dotted list. Alternatively, the last @sc{cdr} of adotted list specification may be another sublist specification (via agrouping or an indirect specification, e.g., @code{(spec . [(morespecs@dots{})])}) whose elements match the non-dotted list arguments.This is useful in recursive specifications such as in the backquoteexample below. Also see the description of a @code{nil} specificationabove for terminating such recursion.Note that a sublist specification written as @code{(specs . nil)}is equivalent to @code{(specs)}, and @code{(specs .(sublist-elements@dots{}))} is equivalent to @code{(specssublist-elements@dots{})}.@end table@c Need to document extensions with &symbol and :symbolHere is a list of additional specifications that may appear only after@code{&define}. See the @code{defun} example below.@table @code@item nameThe argument, a symbol, is the name of the defining form. A defining form is not required to have a name field; and it may havemultiple name fields.@item :nameThis construct does not actually match an argument. The elementfollowing @code{:name} should be a symbol; it is used as an additionalname component for the definition. You can use this to add a unique,static component to the name of the definition. It may be used morethan once.@item argThe argument, a symbol, is the name of an argument of the defining form.However, lambda-list keywords (symbols starting with @samp{&})are not allowed.@item lambda-list@cindex lambda-list (Edebug)This matches a lambda list---the argument list of a lambda expression.@item def-bodyThe argument is the body of code in a definition. This is like@code{body}, described above, but a definition body must be instrumentedwith a different Edebug call that looks up information associated withthe definition. Use @code{def-body} for the highest level list of formswithin the definition.@item def-formThe argument is a single, highest-level form in a definition. This islike @code{def-body}, except use this to match a single form rather thana list of forms. As a special case, @code{def-form} also means thattracing information is not output when the form is executed. See the@code{interactive} example below.@end table@node Backtracking@subsubsection Backtracking in Specifications@cindex backtracking@cindex syntax error (Edebug)If a specification fails to match at some point, this does notnecessarily mean a syntax error will be signaled; instead,@dfn{backtracking} will take place until all alternatives have beenexhausted. Eventually every element of the argument list must bematched by some element in the specification, and every required elementin the specification must match some argument.When a syntax error is detected, it might not be reported until muchlater after higher-level alternatives have been exhausted, and with thepoint positioned further from the real error. But if backtracking isdisabled when an error occurs, it can be reported immediately. Notethat backtracking is also reenabled automatically in several situations;it is reenabled when a new alternative is established by@code{&optional}, @code{&rest}, or @code{&or}, or at the start ofprocessing a sublist, group, or indirect specification. The effect ofenabling or disabling backtracking is limited to the remainder of thelevel currently being processed and lower levels.Backtracking is disabled while matching any of theform specifications (that is, @code{form}, @code{body}, @code{def-form}, and@code{def-body}). These specifications will match any form so any errormust be in the form itself rather than at a higher level.Backtracking is also disabled after successfully matching a quotedsymbol or string specification, since this usually indicates arecognized construct. But if you have a set of alternative constructs thatall begin with the same symbol, you can usually work around thisconstraint by factoring the symbol out of the alternatives, e.g.,@code{["foo" &or [first case] [second case] ...]}.Most needs are satisfied by these two ways that bactracking isautomatically disabled, but occasionally it is useful to explicitlydisable backtracking by using the @code{gate} specification. This isuseful when you know that no higher alternatives could apply. See theexample of the @code{let} specification.@node Specification Examples@subsubsection Specification ExamplesIt may be easier to understand Edebug specifications by studyingthe examples provided here.A @code{let} special form has a sequence of bindings and a body. Eachof the bindings is either a symbol or a sublist with a symbol andoptional expression. In the specification below, notice the @code{gate}inside of the sublist to prevent backtracking once a sublist is found.@example(def-edebug-spec let ((&rest &or symbolp (gate symbolp &optional form)) body))@end exampleEdebug uses the following specifications for @code{defun} and@code{defmacro} and the associated argument list and @code{interactive}specifications. It is necessary to handle interactive forms speciallysince an expression argument it is actually evaluated outside of thefunction body.@smallexample(def-edebug-spec defmacro defun) ; @r{Indirect ref to @code{defun} spec.}(def-edebug-spec defun (&define name lambda-list [&optional stringp] ; @r{Match the doc string, if present.} [&optional ("interactive" interactive)] def-body))(def-edebug-spec lambda-list (([&rest arg] [&optional ["&optional" arg &rest arg]] &optional ["&rest" arg] )))(def-edebug-spec interactive (&optional &or stringp def-form)) ; @r{Notice: @code{def-form}}@end smallexampleThe specification for backquote below illustrates how to matchdotted lists and use @code{nil} to terminate recursion. It alsoillustrates how components of a vector may be matched. (The actualspecification defined by Edebug does not support dotted lists becausedoing so causes very deep recursion that could fail.)@smallexample(def-edebug-spec ` (backquote-form)) ; @r{Alias just for clarity.}(def-edebug-spec backquote-form (&or ([&or "," ",@@"] &or ("quote" backquote-form) form) (backquote-form . [&or nil backquote-form]) (vector &rest backquote-form) sexp))@end smallexample@node Edebug Options@subsection Edebug Options These options affect the behavior of Edebug:@defopt edebug-setup-hookFunctions to call before Edebug is used. Each time it is set to a newvalue, Edebug will call those functions once and then@code{edebug-setup-hook} is reset to @code{nil}. You could use this toload up Edebug specifications associated with a package you are usingbut only when you also use Edebug.@xref{Instrumenting}.@end defopt@defopt edebug-all-defsIf this is non-@code{nil}, normal evaluation of defining forms such as@code{defun} and @code{defmacro} instruments them for Edebug. Thisapplies to @code{eval-defun}, @code{eval-region}, @code{eval-buffer},and @code{eval-current-buffer}.Use the command @kbd{M-x edebug-all-defs} to toggle the value of thisoption. @xref{Instrumenting}.@end defopt@defopt edebug-all-formsIf this is non-@code{nil}, the commands @code{eval-defun},@code{eval-region}, @code{eval-buffer}, and @code{eval-current-buffer}instrument all forms, even those that don't define anything.This doesn't apply to loading or evaluations in the minibuffer.Use the command @kbd{M-x edebug-all-forms} to toggle the value of thisoption. @xref{Instrumenting}.@end defopt@defopt edebug-save-windowsIf this is non-@code{nil}, Edebug saves and restores the windowconfiguration. That takes some time, so if your program does not carewhat happens to the window configurations, it is better to set thisvariable to @code{nil}.If the value is a list, only the listed windows are saved andrestored. You can use the @kbd{W} command in Edebug to change this variableinteractively. @xref{Edebug Display Update}.@end defopt@defopt edebug-save-displayed-buffer-pointsIf this is non-@code{nil}, Edebug saves and restores point in alldisplayed buffers.Saving and restoring point in other buffers is necessary if you aredebugging code that changes the point of a buffer which is displayed ina non-selected window. If Edebug or the user then selects the window,point in that buffer will move to the window's value of point.Saving and restoring point in all buffers is expensive, since itrequires selecting each window twice, so enable this only if you needit. @xref{Edebug Display Update}.@end defopt@defopt edebug-initial-modeIf this variable is non-@code{nil}, it specifies the initial executionmode for Edebug when it is first activated. Possible values are@code{step}, @code{next}, @code{go}, @code{Go-nonstop}, @code{trace},@code{Trace-fast}, @code{continue}, and @code{Continue-fast}.The default value is @code{step}. @xref{Edebug Execution Modes}.@end defopt@defopt edebug-traceNon-@code{nil} means display a trace of function entry and exit.Tracing output is displayed in a buffer named @samp{*edebug-trace*}, onefunction entry or exit per line, indented by the recursion level. The default value is @code{nil}. Also see @code{edebug-tracing}, in @ref{Trace Buffer}.@end defopt@defopt edebug-test-coverage If non-@code{nil}, Edebug tests coverage of all expressions debugged.@xref{Coverage Testing}.@end defopt@defopt edebug-continue-kbd-macro If non-@code{nil}, continue defining or executing any keyboard macrothat is executing outside of Edebug. Use this with caution since it is notdebugged.@xref{Edebug Execution Modes}.@end defopt@defopt edebug-on-errorEdebug binds @code{debug-on-error} to this value, if@code{debug-on-error} was previously @code{nil}. @xref{TrappingErrors}.@end defopt@defopt edebug-on-quitEdebug binds @code{debug-on-quit} to this value, if@code{debug-on-quit} was previously @code{nil}. @xref{TrappingErrors}.@end defopt If you change the values of @code{edebug-on-error} or@code{edebug-on-quit} while Edebug is active, their values won't be useduntil the @emph{next} time Edebug is invoked via a new command.@c Not necessarily a deeper command level.@c A new command is not precisely true, but that is close enough -- dan@defopt edebug-global-break-conditionIf non-@code{nil}, an expression to test for at every stop point.If the result is non-nil, then break. Errors are ignored.@xref{Global Break Condition}.@end defopt