|
428
|
1 @comment -*-texinfo-*-
|
|
|
2
|
|
|
3 @node Edebug, , Compilation Errors, Top
|
|
|
4 @section Edebug
|
|
|
5 @cindex Edebug mode
|
|
|
6
|
|
|
7 @cindex Edebug
|
|
|
8 Edebug is a source-level debugger for XEmacs Lisp programs that
|
|
|
9 provides the following features:
|
|
|
10
|
|
|
11 @itemize @bullet
|
|
|
12 @item
|
|
|
13 Step through evaluation, stopping before and after each expression.
|
|
|
14
|
|
|
15 @item
|
|
|
16 Set conditional or unconditional breakpoints, install embedded
|
|
|
17 breakpoints, or a global break event.
|
|
|
18
|
|
|
19 @item
|
|
|
20 Trace slow or fast stopping briefly at each stop point, or
|
|
|
21 each breakpoint.
|
|
|
22
|
|
|
23 @item
|
|
|
24 Display expression results and evaluate expressions as if outside of
|
|
444
|
25 Edebug. Interface with the custom printing package
|
|
428
|
26 for printing circular structures.
|
|
|
27
|
|
444
|
28 @item
|
|
428
|
29 Automatically reevaluate a list of expressions and
|
|
|
30 display their results each time Edebug updates the display.
|
|
|
31
|
|
|
32 @item
|
|
|
33 Output trace info on function enter and exit.
|
|
|
34
|
|
|
35 @item
|
|
|
36 Errors stop before the source causing the error.
|
|
|
37
|
|
|
38 @item
|
|
|
39 Display backtrace without Edebug calls.
|
|
|
40
|
|
|
41 @item
|
|
|
42 Allow specification of argument evaluation for macros and defining forms.
|
|
|
43
|
|
|
44 @item
|
|
|
45 Provide rudimentary coverage testing and display of frequency counts.
|
|
|
46
|
|
|
47 @end itemize
|
|
|
48
|
|
|
49 The first three sections should tell you enough about Edebug to enable
|
|
|
50 you to use it.
|
|
|
51
|
|
|
52 @menu
|
|
|
53 * Using Edebug:: Introduction to use of Edebug.
|
|
|
54 * Instrumenting:: You must first instrument code.
|
|
|
55 * Edebug Execution Modes:: Execution modes, stopping more or less often.
|
|
|
56 * Jumping:: Commands to jump to a specified place.
|
|
|
57 * Edebug Misc:: Miscellaneous commands.
|
|
|
58 * Breakpoints:: Setting breakpoints to make the program stop.
|
|
|
59 * Trapping Errors:: trapping errors with Edebug.
|
|
|
60 * Edebug Views:: Views inside and outside of Edebug.
|
|
|
61 * Edebug Eval:: Evaluating expressions within Edebug.
|
|
|
62 * Eval List:: Automatic expression evaluation.
|
|
|
63 * Reading in Edebug:: Customization of reading.
|
|
|
64 * Printing in Edebug:: Customization of printing.
|
|
|
65 * Tracing:: How to produce tracing output.
|
|
|
66 * Coverage Testing:: How to test evaluation coverage.
|
|
|
67 * The Outside Context:: Data that Edebug saves and restores.
|
|
|
68 * Instrumenting Macro Calls:: Specifying how to handle macro calls.
|
|
|
69 * Edebug Options:: Option variables for customizing Edebug.
|
|
|
70 @end menu
|
|
|
71
|
|
|
72 @node Using Edebug
|
|
|
73 @subsection Using Edebug
|
|
|
74
|
|
|
75 To debug an XEmacs Lisp program with Edebug, you must first
|
|
|
76 @dfn{instrument} the Lisp code that you want to debug. If you want to
|
|
|
77 just try it now, load @file{edebug.el}, move point into a definition and
|
|
|
78 do @kbd{C-u C-M-x} (@code{eval-defun} with a prefix argument).
|
|
|
79 See @ref{Instrumenting} for alternative ways to instrument code.
|
|
|
80
|
|
|
81 Once a function is instrumented, any call to the function activates
|
|
|
82 Edebug. Activating Edebug may stop execution and let you step through
|
|
|
83 the function, or it may update the display and continue execution while
|
|
|
84 checking for debugging commands, depending on the selected Edebug
|
|
|
85 execution mode. The initial execution mode is @code{step}, by default,
|
|
|
86 which does stop execution. @xref{Edebug Execution Modes}.
|
|
|
87
|
|
|
88 Within Edebug, you normally view an XEmacs buffer showing the source of
|
|
|
89 the Lisp function you are debugging. This is referred to as the
|
|
|
90 @dfn{source code buffer}---but note that it is not always the same
|
|
|
91 buffer depending on which function is currently being executed.
|
|
|
92
|
|
|
93 An arrow at the left margin indicates the line where the function is
|
|
|
94 executing. Point initially shows where within the line the function is
|
|
|
95 executing, but you can move point yourself.
|
|
|
96
|
|
|
97 If you instrument the definition of @code{fac} (shown below) and then
|
|
|
98 execute @code{(fac 3)}, here is what you normally see. Point is at the
|
|
|
99 open-parenthesis before @code{if}.
|
|
|
100
|
|
|
101 @example
|
|
|
102 (defun fac (n)
|
|
|
103 =>@point{}(if (< 0 n)
|
|
|
104 (* n (fac (1- n)))
|
|
|
105 1))
|
|
|
106 @end example
|
|
|
107
|
|
|
108 @cindex stop points
|
|
|
109 The places within a function where Edebug can stop execution are called
|
|
|
110 @dfn{stop points}. These occur both before and after each subexpression
|
|
444
|
111 that is a list, and also after each variable reference.
|
|
428
|
112 Here we show with periods the stop points found in the function
|
|
|
113 @code{fac}:
|
|
|
114
|
|
|
115 @example
|
|
|
116 (defun fac (n)
|
|
|
117 .(if .(< 0 n.).
|
|
|
118 .(* n. .(fac (1- n.).).).
|
|
|
119 1).)
|
|
|
120 @end example
|
|
|
121
|
|
|
122 While the source code buffer is selected, the special commands of Edebug
|
|
|
123 are available in it, in addition to the commands of XEmacs Lisp mode.
|
|
|
124 (The buffer is temporarily made read-only, however.) For example, you
|
|
|
125 can type the Edebug command @key{SPC} to execute until the next stop
|
|
|
126 point. If you type @key{SPC} once after entry to @code{fac}, here is
|
|
|
127 the display you will see:
|
|
|
128
|
|
|
129 @example
|
|
|
130 (defun fac (n)
|
|
|
131 =>(if @point{}(< 0 n)
|
|
|
132 (* n (fac (1- n)))
|
|
|
133 1))
|
|
|
134 @end example
|
|
|
135
|
|
|
136 When Edebug stops execution after an expression, it displays the
|
|
444
|
137 expression's value in the echo area.
|
|
428
|
138
|
|
|
139 Other frequently used commands are @kbd{b} to set a breakpoint at a stop
|
|
|
140 point, @kbd{g} to execute until a breakpoint is reached, and @kbd{q} to
|
|
|
141 exit to the top-level command loop. Type @kbd{?} to display a list of
|
|
|
142 all Edebug commands.
|
|
|
143
|
|
|
144
|
|
|
145 @node Instrumenting
|
|
|
146 @subsection Instrumenting for Edebug
|
|
|
147
|
|
|
148 In order to use Edebug to debug Lisp code, you must first
|
|
|
149 @dfn{instrument} the code. Instrumenting a form inserts additional code
|
|
|
150 into it which invokes Edebug at the proper places. Furthermore, if
|
|
|
151 Edebug detects a syntax error while instrumenting, point is left at the
|
|
|
152 erroneous code and an @code{invalid-read-syntax} error is signaled.
|
|
|
153
|
|
|
154 @kindex C-M-x
|
|
|
155 @findex eval-defun (Edebug)
|
|
|
156 @findex edebug-all-defs
|
|
|
157 Once you have loaded Edebug, the command @kbd{C-M-x}
|
|
|
158 (@code{eval-defun}) is redefined so that when invoked with a prefix
|
|
|
159 argument on a definition, it instruments the definition before
|
|
|
160 evaluating it. (The source code itself is not modified.) If the
|
|
|
161 variable @code{edebug-all-defs} is non-@code{nil}, that inverts the
|
|
|
162 meaning of the prefix argument: then @kbd{C-M-x} instruments the
|
|
|
163 definition @emph{unless} it has a prefix argument. The default value of
|
|
|
164 @code{edebug-all-defs} is @code{nil}. The command @kbd{M-x
|
|
|
165 edebug-all-defs} toggles the value of the variable
|
|
|
166 @code{edebug-all-defs}.
|
|
|
167
|
|
|
168 @findex edebug-all-forms
|
|
|
169 @findex eval-region (Edebug)
|
|
|
170 @findex eval-current-buffer (Edebug)
|
|
|
171 If @code{edebug-all-defs} is non-@code{nil}, then the commands
|
|
|
172 @code{eval-region}, @code{eval-current-buffer}, and @code{eval-buffer}
|
|
|
173 also instrument any definitions they evaluate. Similarly,
|
|
|
174 @code{edebug-all-forms} controls whether @code{eval-region} should
|
|
|
175 instrument @emph{any} form, even non-defining forms. This doesn't apply
|
|
|
176 to loading or evaluations in the minibuffer. The command @kbd{M-x
|
|
|
177 edebug-all-forms} toggles this option.
|
|
|
178
|
|
|
179 @findex edebug-eval-top-level-form
|
|
|
180 Another command, @kbd{M-x edebug-eval-top-level-form}, is available to
|
|
|
181 instrument any top-level form regardless of the value of
|
|
|
182 @code{edebug-all-defs} or @code{edebug-all-forms}.
|
|
|
183
|
|
|
184 Just before Edebug instruments any code, it calls any functions in the
|
|
|
185 variable @code{edebug-setup-hook} and resets its value to @code{nil}.
|
|
|
186 You could use this to load up Edebug specifications associated with a
|
|
|
187 package you are using but only when you also use Edebug. For example,
|
|
|
188 @file{my-specs.el} may be loaded automatically when you use
|
|
|
189 @code{my-package} with Edebug by including the following code in
|
|
|
190 @file{my-package.el}.
|
|
|
191
|
|
|
192 @example
|
|
444
|
193 (add-hook 'edebug-setup-hook
|
|
428
|
194 (function (lambda () (require 'my-specs))))
|
|
|
195 @end example
|
|
|
196
|
|
|
197 While Edebug is active, the command @kbd{I}
|
|
|
198 (@code{edebug-instrument-callee}) instruments the definition of the
|
|
|
199 function or macro called by the list form after point, if is not already
|
|
|
200 instrumented. If the location of the definition is not known to Edebug,
|
|
|
201 this command cannot be used. After loading Edebug, @code{eval-region}
|
|
|
202 records the position of every definition it evaluates, even if not
|
|
|
203 instrumenting it. Also see the command @kbd{i} (@ref{Jumping}) which
|
|
|
204 steps into the callee.
|
|
|
205
|
|
|
206 @cindex special forms (Edebug)
|
|
|
207 @cindex interactive commands (Edebug)
|
|
|
208 @cindex anonymous lambda expressions (Edebug)
|
|
|
209 @cindex Common Lisp (Edebug)
|
|
|
210 @pindex cl.el (Edebug)
|
|
|
211 @pindex cl-specs.el
|
|
|
212 Edebug knows how to instrument all the standard special forms, an
|
|
|
213 interactive form with an expression argument, anonymous lambda
|
|
|
214 expressions, and other defining forms. (Specifications for macros
|
|
|
215 defined by @file{cl.el} (version 2.03) are provided in
|
|
|
216 @file{cl-specs.el}.) Edebug cannot know what a user-defined macro will
|
|
|
217 do with the arguments of a macro call so you must tell it. See
|
|
|
218 @ref{Instrumenting Macro Calls} for the details.
|
|
|
219
|
|
|
220 @findex eval-expression (Edebug)
|
|
|
221 Note that a couple ways remain to evaluate expressions without
|
|
|
222 instrumenting them. Loading a file via the @code{load} subroutine does
|
|
|
223 not instrument expressions for Edebug. Evaluations in the minibuffer
|
|
|
224 via @code{eval-expression} (@kbd{M-ESC}) are not instrumented.
|
|
|
225
|
|
|
226 To remove instrumentation from a definition, simply reevaluate it with
|
|
|
227 one of the non-instrumenting commands, or reload the file.
|
|
|
228
|
|
|
229 See @ref{Edebug Eval} for other evaluation functions available
|
|
|
230 inside of Edebug.
|
|
|
231
|
|
|
232
|
|
|
233 @node Edebug Execution Modes
|
|
|
234 @subsection Edebug Execution Modes
|
|
|
235
|
|
|
236 @cindex Edebug execution modes
|
|
|
237 Edebug supports several execution modes for running the program you are
|
|
|
238 debugging. We call these alternatives @dfn{Edebug execution modes}; do
|
|
|
239 not confuse them with major or minor modes. The current Edebug
|
|
|
240 execution mode determines how Edebug displays the progress of the
|
|
|
241 evaluation, whether it stops at each stop point, or continues to the
|
|
|
242 next breakpoint, for example.
|
|
|
243
|
|
|
244 Normally, you specify the Edebug execution mode by typing a command
|
|
|
245 to continue the program in a certain mode. Here is a table of these
|
|
|
246 commands. All except for @kbd{S} resume execution of the program, at
|
|
|
247 least for a certain distance.
|
|
|
248
|
|
|
249 @table @kbd
|
|
|
250 @item S
|
|
|
251 Stop: don't execute any more of the program for now, just wait for more
|
|
|
252 Edebug commands (@code{edebug-stop}).
|
|
|
253
|
|
|
254 @item @key{SPC}
|
|
|
255 Step: stop at the next stop point encountered (@code{edebug-step-mode}).
|
|
|
256
|
|
|
257 @item n
|
|
|
258 Next: stop at the next stop point encountered after an expression
|
|
|
259 (@code{edebug-next-mode}). Also see @code{edebug-forward-sexp} in
|
|
|
260 @ref{Edebug Misc}.
|
|
|
261
|
|
|
262 @item t
|
|
|
263 Trace: pause one second at each Edebug stop point (@code{edebug-trace-mode}).
|
|
|
264
|
|
|
265 @item T
|
|
|
266 Rapid trace: update at each stop point, but don't actually
|
|
|
267 pause (@code{edebug-Trace-fast-mode}).
|
|
|
268
|
|
|
269 @item g
|
|
|
270 Go: run until the next breakpoint (@code{edebug-go-mode}). @xref{Breakpoints}.
|
|
|
271
|
|
|
272 @item c
|
|
|
273 Continue: pause for one second at each breakpoint, but don't stop
|
|
|
274 (@code{edebug-continue-mode}).
|
|
|
275
|
|
|
276 @item C
|
|
|
277 Rapid continue: update at each breakpoint, but don't actually pause
|
|
|
278 (@code{edebug-Continue-fast-mode}).
|
|
|
279
|
|
|
280 @item G
|
|
|
281 Go non-stop: ignore breakpoints (@code{edebug-Go-nonstop-mode}). You
|
|
|
282 can still stop the program by hitting any key.
|
|
|
283 @end table
|
|
|
284
|
|
|
285 In general, the execution modes earlier in the above list run the
|
|
|
286 program more slowly or stop sooner.
|
|
|
287
|
|
|
288 When you enter a new Edebug level, the initial execution mode comes from
|
|
|
289 the value of the variable @code{edebug-initial-mode}. By default, this
|
|
|
290 specifies @code{step} mode. Note that you may reenter the same Edebug
|
|
444
|
291 level several times if, for example, an instrumented function is called
|
|
428
|
292 several times from one command.
|
|
|
293
|
|
|
294 While executing or tracing, you can interrupt the execution by typing
|
|
|
295 any Edebug command. Edebug stops the program at the next stop point and
|
|
|
296 then executes the command that you typed. For example, typing @kbd{t}
|
|
|
297 during execution switches to trace mode at the next stop point. You can
|
|
|
298 use @kbd{S} to stop execution without doing anything else.
|
|
|
299
|
|
|
300 If your function happens to read input, a character you hit intending to
|
|
|
301 interrupt execution may be read by the function instead. You can avoid
|
|
|
302 such unintended results by paying attention to when your program wants
|
|
|
303 input.
|
|
|
304
|
|
|
305 @cindex keyboard macros (Edebug)
|
|
|
306 Keyboard macros containing Edebug commands do not work; when you exit
|
|
|
307 from Edebug, to resume the program, whether you are defining or
|
|
|
308 executing a keyboard macro is forgotten. Also, defining or executing a
|
|
|
309 keyboard macro outside of Edebug does not affect the command loop inside
|
|
|
310 Edebug. This is usually an advantage. But see
|
|
|
311 @code{edebug-continue-kbd-macro}.
|
|
|
312
|
|
|
313
|
|
|
314 @node Jumping
|
|
|
315 @subsection Jumping
|
|
|
316
|
|
|
317 Commands described here let you jump to a specified location.
|
|
|
318 All, except @kbd{i}, use temporary breakpoints to establish the stop
|
|
|
319 point and then switch to @code{go} mode. Any other breakpoint reached
|
|
|
320 before the intended stop point will also stop execution. See
|
|
|
321 @ref{Breakpoints} for the details on breakpoints.
|
|
|
322
|
|
|
323 @table @kbd
|
|
|
324 @item f
|
|
|
325 Run the program forward over one expression
|
|
|
326 (@code{edebug-forward-sexp}). More precisely, set a temporary
|
|
|
327 breakpoint at the position that @kbd{C-M-f} would reach, then execute in
|
|
|
328 @code{go} mode so that the program will stop at breakpoints.
|
|
|
329
|
|
|
330 With a prefix argument @var{n}, the temporary breakpoint is placed
|
|
|
331 @var{n} sexps beyond point. If the containing list ends before @var{n}
|
|
|
332 more elements, then the place to stop is after the containing
|
|
|
333 expression.
|
|
|
334
|
|
|
335 Be careful that the position @kbd{C-M-f} finds is a place that the
|
|
|
336 program will really get to; this may not be true in a
|
|
|
337 @code{cond}, for example.
|
|
|
338
|
|
|
339 This command does @code{forward-sexp} starting at point rather than the
|
|
|
340 stop point. If you want to execute one expression from the current stop
|
|
|
341 point, type @kbd{w} first, to move point there.
|
|
|
342
|
|
|
343 @item o
|
|
|
344 Continue ``out of'' an expression (@code{edebug-step-out}). It places a
|
|
444
|
345 temporary breakpoint at the end of the sexp containing point.
|
|
428
|
346
|
|
|
347 If the containing sexp is a function definition itself, it continues
|
|
|
348 until just before the last sexp in the definition. If that is where you
|
|
|
349 are now, it returns from the function and then stops. In other words,
|
|
|
350 this command does not exit the currently executing function unless you
|
|
|
351 are positioned after the last sexp.
|
|
|
352
|
|
|
353 @item I
|
|
|
354 Step into the function or macro after point after first ensuring that it
|
|
|
355 is instrumented. It does this by calling @code{edebug-on-entry} and
|
|
|
356 then switching to @code{go} mode.
|
|
|
357
|
|
|
358 Although the automatic instrumentation is convenient, it is not
|
|
|
359 later automatically uninstrumented.
|
|
|
360
|
|
|
361 @item h
|
|
|
362 Proceed to the stop point near where point is using a temporary
|
|
|
363 breakpoint (@code{edebug-goto-here}).
|
|
|
364
|
|
|
365 @end table
|
|
|
366
|
|
|
367 All the commands in this section may fail to work as expected in case
|
|
|
368 of nonlocal exit, because a nonlocal exit can bypass the temporary
|
|
|
369 breakpoint where you expected the program to stop.
|
|
|
370
|
|
|
371 @node Edebug Misc
|
|
|
372 @subsection Miscellaneous
|
|
|
373
|
|
|
374 Some miscellaneous commands are described here.
|
|
|
375
|
|
|
376 @table @kbd
|
|
|
377 @item ?
|
|
|
378 Display the help message for Edebug (@code{edebug-help}).
|
|
|
379
|
|
|
380 @item C-]
|
|
|
381 Abort one level back to the previous command level
|
|
|
382 (@code{abort-recursive-edit}).
|
|
|
383
|
|
|
384 @item q
|
|
|
385 Return to the top level editor command loop (@code{top-level}). This
|
|
|
386 exits all recursive editing levels, including all levels of Edebug
|
|
|
387 activity. However, instrumented code protected with
|
|
|
388 @code{unwind-protect} or @code{condition-case} forms may resume
|
|
|
389 debugging.
|
|
|
390
|
|
|
391 @item Q
|
|
|
392 Like @kbd{q} but don't stop even for protected code
|
|
|
393 (@code{top-level-nonstop}).
|
|
|
394
|
|
|
395 @item r
|
|
|
396 Redisplay the most recently known expression result in the echo area
|
|
|
397 (@code{edebug-previous-result}).
|
|
|
398
|
|
|
399 @item d
|
|
|
400 Display a backtrace, excluding Edebug's own functions for clarity
|
|
|
401 (@code{edebug-backtrace}).
|
|
|
402
|
|
|
403 You cannot use debugger commands in the backtrace buffer in Edebug as
|
|
|
404 you would in the standard debugger.
|
|
|
405
|
|
|
406 The backtrace buffer is killed automatically when you continue
|
|
|
407 execution.
|
|
|
408 @end table
|
|
|
409
|
|
|
410 From the Edebug recursive edit, you may invoke commands that activate
|
|
|
411 Edebug again recursively. Any time Edebug is active, you can quit to
|
|
|
412 the top level with @kbd{q} or abort one recursive edit level with
|
|
444
|
413 @kbd{C-]}. You can display a backtrace of all the
|
|
428
|
414 pending evaluations with @kbd{d}.
|
|
|
415
|
|
|
416
|
|
|
417 @node Breakpoints
|
|
|
418 @subsection Breakpoints
|
|
|
419
|
|
|
420 @cindex breakpoints
|
|
|
421 There are three more ways to stop execution once it has started:
|
|
|
422 breakpoints, the global break condition, and embedded breakpoints.
|
|
|
423
|
|
|
424 While using Edebug, you can specify @dfn{breakpoints} in the program you
|
|
|
425 are testing: points where execution should stop. You can set a
|
|
|
426 breakpoint at any stop point, as defined in @ref{Using Edebug}. For
|
|
|
427 setting and unsetting breakpoints, the stop point that is affected is
|
|
|
428 the first one at or after point in the source code buffer. Here are the
|
|
|
429 Edebug commands for breakpoints:
|
|
|
430
|
|
|
431 @table @kbd
|
|
|
432 @item b
|
|
|
433 Set a breakpoint at the stop point at or after point
|
|
|
434 (@code{edebug-set-breakpoint}). If you use a prefix argument, the
|
|
|
435 breakpoint is temporary (it turns off the first time it stops the
|
|
|
436 program).
|
|
|
437
|
|
|
438 @item u
|
|
|
439 Unset the breakpoint (if any) at the stop point at or after the current
|
|
|
440 point (@code{edebug-unset-breakpoint}).
|
|
|
441
|
|
|
442 @item x @var{condition} @key{RET}
|
|
|
443 Set a conditional breakpoint which stops the program only if
|
|
|
444 @var{condition} evaluates to a non-@code{nil} value
|
|
|
445 (@code{edebug-set-conditional-breakpoint}). If you use a prefix
|
|
|
446 argument, the breakpoint is temporary (it turns off the first time it
|
|
|
447 stops the program).
|
|
|
448
|
|
|
449 @item B
|
|
|
450 Move point to the next breakpoint in the definition
|
|
|
451 (@code{edebug-next-breakpoint}).
|
|
|
452 @end table
|
|
|
453
|
|
|
454 While in Edebug, you can set a breakpoint with @kbd{b} and unset one
|
|
|
455 with @kbd{u}. First you must move point to a position at or before the
|
|
|
456 desired Edebug stop point, then hit the key to change the breakpoint.
|
|
|
457 Unsetting a breakpoint that has not been set does nothing.
|
|
|
458
|
|
|
459 Reevaluating or reinstrumenting a definition clears all its breakpoints.
|
|
|
460
|
|
|
461 A @dfn{conditional breakpoint} tests a condition each time the program
|
|
|
462 gets there. To set a conditional breakpoint, use @kbd{x}, and specify
|
|
|
463 the condition expression in the minibuffer. Setting a conditional
|
|
|
464 breakpoint at a stop point that already has a conditional breakpoint
|
|
|
465 puts the current condition expression in the minibuffer so you can edit
|
|
|
466 it.
|
|
|
467
|
|
|
468 You can make both conditional and unconditional breakpoints
|
|
|
469 @dfn{temporary} by using a prefix arg to the command to set the
|
|
|
470 breakpoint. After breaking at a temporary breakpoint, it is
|
|
|
471 automatically cleared.
|
|
|
472
|
|
|
473 Edebug always stops or pauses at a breakpoint except when the Edebug
|
|
|
474 mode is @code{Go-nonstop}. In that mode, it ignores breakpoints entirely.
|
|
|
475
|
|
|
476 To find out where your breakpoints are, use @kbd{B}, which
|
|
|
477 moves point to the next breakpoint in the definition following point, or
|
|
|
478 to the first breakpoint if there are no following breakpoints. This
|
|
|
479 command does not continue execution---it just moves point in the buffer.
|
|
|
480
|
|
|
481 @menu
|
|
444
|
482 * Global Break Condition:: Breaking on an event.
|
|
428
|
483 * Embedded Breakpoints:: Embedding breakpoints in code.
|
|
|
484 @end menu
|
|
|
485
|
|
|
486
|
|
|
487 @node Global Break Condition
|
|
|
488 @subsubsection Global Break Condition
|
|
|
489
|
|
|
490 @cindex stopping on events
|
|
|
491 @cindex global break condition
|
|
|
492 In contrast to breaking when execution reaches specified locations,
|
|
|
493 you can also cause a break when a certain event occurs. The @dfn{global
|
|
|
494 break condition} is a condition that is repeatedly evaluated at every
|
|
|
495 stop point. If it evaluates to a non-@code{nil} value, then execution
|
|
|
496 is stopped or paused depending on the execution mode, just like a
|
|
|
497 breakpoint. Any errors that might occur as a result of evaluating the
|
|
444
|
498 condition are ignored, as if the result were @code{nil}.
|
|
428
|
499
|
|
|
500 @findex edebug-set-global-break-condition
|
|
|
501 @vindex edebug-global-break-condition
|
|
|
502 You can set or edit the condition expression, stored in
|
|
|
503 @code{edebug-global-break-condition}, using @kbd{X}
|
|
|
504 (@code{edebug-set-global-break-condition}).
|
|
|
505
|
|
|
506 Using the global break condition is perhaps the fastest way
|
|
|
507 to find where in your code some event occurs, but since it is rather
|
|
|
508 expensive you should reset the condition to @code{nil} when not in use.
|
|
|
509
|
|
|
510
|
|
|
511 @node Embedded Breakpoints
|
|
|
512 @subsubsection Embedded Breakpoints
|
|
|
513
|
|
|
514 @findex edebug
|
|
|
515 @cindex embedded breakpoints
|
|
|
516 Since all breakpoints in a definition are cleared each time you
|
|
|
517 reinstrument it, you might rather create an @dfn{embedded breakpoint}
|
|
|
518 which is simply a call to the function @code{edebug}. You can, of
|
|
|
519 course, make such a call conditional. For example, in the @code{fac}
|
|
|
520 function, insert the first line as shown below to stop when the argument
|
|
|
521 reaches zero:
|
|
|
522
|
|
|
523 @example
|
|
|
524 (defun fac (n)
|
|
|
525 (if (= n 0) (edebug))
|
|
|
526 (if (< 0 n)
|
|
|
527 (* n (fac (1- n)))
|
|
|
528 1))
|
|
|
529 @end example
|
|
|
530
|
|
|
531 When the @code{fac} definition is instrumented and the function is
|
|
|
532 called, Edebug will stop before the call to @code{edebug}. Depending on
|
|
|
533 the execution mode, Edebug will stop or pause.
|
|
|
534
|
|
|
535 However, if no instrumented code is being executed, calling
|
|
|
536 @code{edebug} will instead invoke @code{debug}. Calling @code{debug}
|
|
|
537 will always invoke the standard backtrace debugger.
|
|
|
538
|
|
|
539
|
|
|
540 @node Trapping Errors
|
|
|
541 @subsection Trapping Errors
|
|
|
542
|
|
|
543 @vindex edebug-on-error
|
|
|
544 @vindex edebug-on-quit
|
|
|
545 An error may be signaled by subroutines or XEmacs Lisp code. If a signal
|
|
|
546 is not handled by a @code{condition-case}, this indicates an
|
|
|
547 unrecognized situation has occurred. If Edebug is not active when an
|
|
|
548 unhandled error is signaled, @code{debug} is run normally (if
|
|
|
549 @code{debug-on-error} is non-@code{nil}). But while Edebug is active,
|
|
|
550 @code{debug-on-error} and @code{debug-on-quit} are bound to
|
|
|
551 @code{edebug-on-error} and @code{edebug-on-quit}, which are both
|
|
|
552 @code{t} by default. Actually, if @code{debug-on-error} already has
|
|
|
553 a non-@code{nil} value, that value is still used.
|
|
|
554
|
|
|
555 It is best to change the values of @code{edebug-on-error} or
|
|
|
556 @code{edebug-on-quit} when Edebug is not active since their values won't
|
|
|
557 be used until the next time Edebug is invoked at a deeper command level.
|
|
|
558 If you only change @code{debug-on-error} or @code{debug-on-quit} while
|
|
|
559 Edebug is active, these changes will be forgotten when Edebug becomes
|
|
|
560 inactive. Furthermore, during Edebug's recursive edit, these variables
|
|
|
561 are bound to the values they had outside of Edebug.
|
|
|
562
|
|
|
563 Edebug shows you the last stop point that it knew about before the
|
|
|
564 error was signaled. This may be the location of a call to a function
|
|
|
565 which was not instrumented, within which the error actually occurred.
|
|
|
566 For an unbound variable error, the last known stop point might be quite
|
|
|
567 distant from the offending variable. If the cause of the error is not
|
|
|
568 obvious at first, note that you can also get a full backtrace inside of
|
|
|
569 Edebug (see @ref{Edebug Misc}).
|
|
|
570
|
|
|
571 Edebug can also trap signals even if they are handled. If
|
|
|
572 @code{debug-on-error} is a list of signal names, Edebug will stop when
|
|
|
573 any of these errors are signaled. Edebug shows you the last known stop
|
|
|
574 point just as for unhandled errors. After you continue execution, the
|
|
|
575 error is signaled again (but without being caught by Edebug). Edebug
|
|
|
576 can only trap errors that are handled if they are signaled in Lisp code
|
|
|
577 (not subroutines) since it does so by temporarily replacing the
|
|
|
578 @code{signal} function.
|
|
|
579
|
|
|
580
|
|
|
581 @node Edebug Views
|
|
|
582 @subsection Edebug Views
|
|
|
583
|
|
|
584 The following Edebug commands let you view aspects of the buffer and
|
|
|
585 window status that obtained before entry to Edebug.
|
|
|
586
|
|
|
587 @table @kbd
|
|
|
588 @item v
|
|
|
589 View the outside window configuration (@code{edebug-view-outside}).
|
|
|
590
|
|
|
591 @item p
|
|
|
592 Temporarily display the outside current buffer with point at its outside
|
|
|
593 position (@code{edebug-bounce-point}). If prefix arg is supplied, sit for
|
|
|
594 that many seconds instead.
|
|
|
595
|
|
|
596 @item w
|
|
|
597 Move point back to the current stop point (@code{edebug-where}) in the
|
|
|
598 source code buffer. Also, if you use this command in another window
|
|
|
599 displaying the same buffer, this window will be used instead to
|
|
|
600 display the buffer in the future.
|
|
|
601
|
|
|
602 @item W
|
|
|
603 Toggle the @code{edebug-save-windows} variable which indicates whether
|
|
|
604 the outside window configuration is saved and restored
|
|
|
605 (@code{edebug-toggle-save-windows}). Also, each time it is toggled on,
|
|
|
606 make the outside window configuration the same as the current window
|
|
|
607 configuration.
|
|
|
608
|
|
|
609 With a prefix argument, @code{edebug-toggle-save-windows} only toggles
|
|
|
610 saving and restoring of the selected window. To specify a window that
|
|
|
611 is not displaying the source code buffer, you must use @kbd{C-xXW} from
|
|
|
612 the global keymap.
|
|
|
613
|
|
|
614
|
|
|
615 @end table
|
|
|
616
|
|
|
617 You can view the outside window configuration with @kbd{v} or just
|
|
|
618 bounce to the current point in the current buffer with @kbd{p}, even if
|
|
|
619 it is not normally displayed. After moving point, you may wish to pop
|
|
|
620 back to the stop point with @kbd{w} from a source code buffer.
|
|
|
621
|
|
|
622 By using @kbd{W} twice, Edebug again saves and restores the
|
|
|
623 outside window configuration, but to the current configuration. This is
|
|
|
624 a convenient way to, for example, add another buffer to be displayed
|
|
|
625 whenever Edebug is active. However, the automatic redisplay of
|
|
|
626 @samp{*edebug*} and @samp{*edebug-trace*} may conflict with the buffers
|
|
|
627 you wish to see unless you have enough windows open.
|
|
|
628
|
|
|
629
|
|
|
630 @node Edebug Eval
|
|
|
631 @subsection Evaluation
|
|
|
632
|
|
|
633 While within Edebug, you can evaluate expressions ``as if'' Edebug were
|
|
|
634 not running. Edebug tries to be invisible to the expression's
|
|
|
635 evaluation and printing. Evaluation of expressions that cause side
|
|
|
636 effects will work as expected except for things that Edebug explicitly
|
|
|
637 saves and restores. See @ref{The Outside Context} for details on this
|
|
|
638 process. Also see @ref{Reading in Edebug} and @ref{Printing in Edebug}
|
|
|
639 for topics related to evaluation.
|
|
|
640
|
|
|
641 @table @kbd
|
|
|
642 @item e @var{exp} @key{RET}
|
|
|
643 Evaluate expression @var{exp} in the context outside of Edebug
|
|
|
644 (@code{edebug-eval-expression}). In other words, Edebug tries to avoid
|
|
|
645 altering the effect of @var{exp}.
|
|
|
646
|
|
|
647 @item M-@key{ESC} @var{exp} @key{RET}
|
|
|
648 Evaluate expression @var{exp} in the context of Edebug itself.
|
|
|
649
|
|
|
650 @item C-x C-e
|
|
|
651 Evaluate the expression before point, in the context outside of Edebug
|
|
|
652 (@code{edebug-eval-last-sexp}).
|
|
|
653 @end table
|
|
|
654
|
|
|
655 @cindex lexical binding (Edebug)
|
|
|
656 Edebug supports evaluation of expressions containing references to
|
|
|
657 lexically bound symbols created by the following constructs in
|
|
|
658 @file{cl.el} (version 2.03 or later): @code{lexical-let},
|
|
|
659 @code{macrolet}, and @code{symbol-macrolet}.
|
|
|
660
|
|
|
661
|
|
|
662 @node Eval List
|
|
|
663 @subsection Evaluation List Buffer
|
|
|
664
|
|
|
665 You can use the @dfn{evaluation list buffer}, called @samp{*edebug*}, to
|
|
|
666 evaluate expressions interactively. You can also set up the
|
|
|
667 @dfn{evaluation list} of expressions to be evaluated automatically each
|
|
|
668 time Edebug updates the display.
|
|
|
669
|
|
|
670 @table @kbd
|
|
|
671 @item E
|
|
|
672 Switch to the evaluation list buffer @samp{*edebug*}
|
|
|
673 (@code{edebug-visit-eval-list}).
|
|
|
674 @end table
|
|
|
675
|
|
|
676 In the @samp{*edebug*} buffer you can use the commands of Lisp
|
|
|
677 Interaction as well as these special commands:
|
|
|
678
|
|
|
679 @table @kbd
|
|
|
680 @item LFD
|
|
|
681 Evaluate the expression before point, in the outside context, and insert
|
|
|
682 the value in the buffer (@code{edebug-eval-print-last-sexp}).
|
|
|
683
|
|
|
684 @item C-x C-e
|
|
|
685 Evaluate the expression before point, in the context outside of Edebug
|
|
|
686 (@code{edebug-eval-last-sexp}).
|
|
|
687
|
|
|
688 @item C-c C-u
|
|
|
689 Build a new evaluation list from the first expression of each group,
|
|
|
690 reevaluate and redisplay (@code{edebug-update-eval-list}). Groups are
|
|
|
691 separated by comment lines.
|
|
|
692
|
|
|
693 @item C-c C-d
|
|
|
694 Delete the evaluation list group that point is in
|
|
|
695 (@code{edebug-delete-eval-item}).
|
|
|
696
|
|
|
697 @item C-c C-w
|
|
|
698 Switch back to the source code buffer at the current stop point
|
|
|
699 (@code{edebug-where}).
|
|
|
700 @end table
|
|
|
701
|
|
|
702 You can evaluate expressions in the evaluation list window with
|
|
|
703 @kbd{LFD} or @kbd{C-x C-e}, just as you would in @samp{*scratch*};
|
|
|
704 but they are evaluated in the context outside of Edebug.
|
|
|
705
|
|
|
706 @cindex evaluation list (Edebug)
|
|
|
707 The expressions you enter interactively (and their results) are lost
|
|
|
708 when you continue execution unless you add them to the
|
|
|
709 evaluation list with @kbd{C-c C-u}. This command builds a new list from
|
|
|
710 the first expression of each @dfn{evaluation list group}. Groups are
|
|
|
711 separated by comment lines. Be careful not to add expressions that
|
|
|
712 execute instrumented code otherwise an infinite loop will result.
|
|
|
713
|
|
|
714 When the evaluation list is redisplayed, each expression is displayed
|
|
|
715 followed by the result of evaluating it, and a comment line. If an
|
|
|
716 error occurs during an evaluation, the error message is displayed in a
|
|
|
717 string as if it were the result. Therefore expressions that, for
|
|
|
718 example, use variables not currently valid do not interrupt your
|
|
|
719 debugging.
|
|
|
720
|
|
|
721 Here is an example of what the evaluation list window looks like after
|
|
|
722 several expressions have been added to it:
|
|
|
723
|
|
|
724 @smallexample
|
|
|
725 (current-buffer)
|
|
|
726 #<buffer *scratch*>
|
|
|
727 ;---------------------------------------------------------------
|
|
|
728 (selected-window)
|
|
|
729 #<window 16 on *scratch*>
|
|
|
730 ;---------------------------------------------------------------
|
|
|
731 (point)
|
|
|
732 196
|
|
|
733 ;---------------------------------------------------------------
|
|
|
734 bad-var
|
|
|
735 "Symbol's value as variable is void: bad-var"
|
|
|
736 ;---------------------------------------------------------------
|
|
|
737 (recursion-depth)
|
|
|
738 0
|
|
|
739 ;---------------------------------------------------------------
|
|
|
740 this-command
|
|
|
741 eval-last-sexp
|
|
|
742 ;---------------------------------------------------------------
|
|
|
743 @end smallexample
|
|
|
744
|
|
|
745 To delete a group, move point into it and type @kbd{C-c C-d}, or simply
|
|
|
746 delete the text for the group and update the evaluation list with
|
|
|
747 @kbd{C-c C-u}. When you add a new group, be sure it is separated from
|
|
|
748 its neighbors by a comment line.
|
|
|
749
|
|
|
750 After selecting @samp{*edebug*}, you can return to the source code
|
|
|
751 buffer with @kbd{C-c C-w}. The @samp{*edebug*} buffer is killed when
|
|
|
752 you continue execution, and recreated next time it is needed.
|
|
|
753
|
|
|
754
|
|
|
755 @node Reading in Edebug
|
|
|
756 @subsection Reading in Edebug
|
|
|
757
|
|
|
758 @cindex reading (Edebug)
|
|
|
759 To instrument a form, Edebug first reads the whole form. Edebug
|
|
|
760 replaces the standard Lisp Reader with its own reader that remembers the
|
|
|
761 positions of expressions. This reader is used by the Edebug
|
|
|
762 replacements for @code{eval-region}, @code{eval-defun},
|
|
|
763 @code{eval-buffer}, and @code{eval-current-buffer}.
|
|
|
764
|
|
|
765 @pindex cl-read
|
|
|
766 Another package, @file{cl-read.el}, replaces the standard reader with
|
|
|
767 one that understands Common Lisp reader macros. If you use that
|
|
|
768 package, Edebug will automatically load @file{edebug-cl-read.el} to
|
|
|
769 provide corresponding reader macros that remember positions of
|
|
|
770 expressions. If you define new reader macros, you will have to define
|
|
|
771 similar reader macros for Edebug.
|
|
|
772
|
|
|
773
|
|
|
774 @node Printing in Edebug
|
|
|
775 @subsection Printing in Edebug
|
|
|
776
|
|
|
777 @cindex printing (Edebug)
|
|
|
778 @cindex printing circular structures
|
|
|
779 @pindex cust-print
|
|
|
780 If the result of an expression in your program contains a circular
|
|
|
781 reference, you may get an error when Edebug attempts to print it. You
|
|
|
782 can set @code{print-length} to a non-zero value to limit the print
|
|
|
783 length of lists (the number of cdrs), and in Emacs 19, set
|
|
|
784 @code{print-level} to a non-zero value to limit the print depth of
|
|
|
785 lists. But you can print such circular structures and structures that
|
|
|
786 share elements more informatively by using the @file{cust-print}
|
|
|
787 package.
|
|
|
788
|
|
|
789 To load @file{cust-print} and activate custom printing only for Edebug,
|
|
|
790 simply use the command @kbd{M-x edebug-install-custom-print}. To
|
|
|
791 restore the standard print functions, use @kbd{M-x
|
|
|
792 edebug-uninstall-custom-print}. You can also activate custom printing
|
|
|
793 for printing in any Lisp code; see the package for details.
|
|
|
794
|
|
|
795 Here is an example of code that creates a circular structure:
|
|
|
796
|
|
|
797 @example
|
|
|
798 (progn
|
|
|
799 (edebug-install-custom-print)
|
|
|
800 (setq a '(x y))
|
|
|
801 (setcar a a))
|
|
|
802 @end example
|
|
|
803
|
|
|
804 Edebug will print the result of the @code{setcar} as @samp{Result:
|
|
|
805 #1=(#1# y)}. The @samp{#1=} notation names the structure that follows
|
|
|
806 it, and the @samp{#1#} notation references the previously named
|
|
|
807 structure. This notation is used for any shared elements of lists or
|
|
|
808 vectors.
|
|
|
809
|
|
|
810 @vindex edebug-print-length
|
|
|
811 @vindex edebug-print-level
|
|
|
812 @vindex edebug-print-circle
|
|
|
813 @vindex print-readably
|
|
|
814 Independent of whether @file{cust-print} is active, while printing
|
|
|
815 results Edebug binds @code{print-length}, @code{print-level}, and
|
|
|
816 @code{print-circle} to @code{edebug-print-length} (@code{50}),
|
|
|
817 @code{edebug-print-level} (@code{50}), and @code{edebug-print-circle}
|
|
|
818 (@code{t}) respectively, if these values are non-@code{nil}. Also,
|
|
|
819 @code{print-readably} is bound to @code{nil} since some objects simply
|
|
|
820 cannot be printed readably.
|
|
|
821
|
|
|
822
|
|
|
823 @node Tracing
|
|
|
824 @subsection Tracing
|
|
|
825
|
|
|
826 @cindex tracing
|
|
|
827 In addition to automatic stepping through source code, which is also
|
|
|
828 called @emph{tracing} (see @ref{Edebug Execution Modes}), Edebug can
|
|
|
829 produce a traditional trace listing of execution in a separate buffer,
|
|
|
830 @samp{*edebug-trace*}.
|
|
|
831
|
|
|
832 @findex edebug-print-trace-before
|
|
|
833 @findex edebug-print-trace-after
|
|
444
|
834 If the variable @code{edebug-trace} is non-@code{nil}, each function entry and
|
|
428
|
835 exit adds lines to the trace buffer. On function entry, Edebug prints
|
|
|
836 @samp{::::@{} followed by the function name and argument values. On
|
|
|
837 function exit, Edebug prints @samp{::::@}} followed by the function name
|
|
|
838 and result of the function. The number of @samp{:}s is computed from
|
|
|
839 the recursion depth. The balanced braces in the trace buffer can be
|
|
|
840 used to find the matching beginning or end of function calls. These
|
|
|
841 displays may be customized by replacing the functions
|
|
|
842 @code{edebug-print-trace-before} and @code{edebug-print-trace-after},
|
|
|
843 which take an arbitrary message string to print.
|
|
|
844
|
|
|
845 @findex edebug-tracing
|
|
|
846 The macro @code{edebug-tracing} provides tracing similar to function
|
|
|
847 enter and exit tracing, but for arbitrary expressions. This macro
|
|
|
848 should be explicitly inserted by you around expressions you wish to
|
|
|
849 trace the execution of. The first argument is a message string
|
|
|
850 (evaluated), and the rest are expressions to evaluate. The result of
|
|
|
851 the last expression is returned.
|
|
|
852
|
|
|
853 @findex edebug-trace
|
|
|
854 Finally, you can insert arbitrary strings into the trace buffer with
|
|
|
855 explicit calls to @code{edebug-trace}. The arguments of this function
|
|
|
856 are the same as for @code{message}, but a newline is always inserted
|
|
|
857 after each string printed in this way.
|
|
|
858
|
|
|
859 @code{edebug-tracing} and @code{edebug-trace} insert lines in the trace
|
|
|
860 buffer even if Edebug is not active. Every time the trace buffer is
|
|
|
861 added to, the window is scrolled to show the last lines inserted.
|
|
|
862 (There may be some display problems if you use tracing along with the
|
|
|
863 evaluation list.)
|
|
|
864
|
|
|
865
|
|
|
866 @node Coverage Testing
|
|
|
867 @subsection Coverage Testing
|
|
|
868
|
|
|
869 @cindex coverage testing
|
|
|
870 @cindex frequency counts
|
|
|
871 @cindex performance analysis
|
|
|
872 Edebug provides a rudimentary coverage tester and display of execution
|
|
|
873 frequency. Frequency counts are always accumulated, both before and
|
|
|
874 after evaluation of each instrumented expression, even if the execution
|
|
|
875 mode is @code{Go-nonstop}. Coverage testing is only done if the option
|
|
|
876 @code{edebug-test-coverage} is non-@code{nil} because this is relatively
|
|
|
877 expensive. Both data sets are displayed by @kbd{M-x
|
|
|
878 edebug-display-freq-count}.
|
|
|
879
|
|
|
880 @deffn Command edebug-display-freq-count
|
|
|
881 Display the frequency count data for each line of the current
|
|
|
882 definition. The frequency counts are inserted as comment lines after
|
|
|
883 each line, and you can undo all insertions with one @code{undo} command.
|
|
|
884 The counts are inserted starting under the @kbd{(} before an expression
|
|
|
885 or the @kbd{)} after an expression, or on the last char of a symbol.
|
|
|
886 The counts are only displayed when they differ from previous counts on
|
|
|
887 the same line.
|
|
|
888
|
|
|
889 If coverage is being tested, whenever all known results of an expression
|
|
|
890 are @code{eq}, the char @kbd{=} will be appended after the count
|
|
|
891 for that expression. Note that this is always the case for an
|
|
|
892 expression only evaluated once.
|
|
|
893
|
|
|
894 To clear the frequency count and coverage data for a definition,
|
|
|
895 reinstrument it.
|
|
|
896
|
|
|
897 @end deffn
|
|
|
898
|
|
|
899 For example, after evaluating @code{(fac 5)} with an embedded
|
|
|
900 breakpoint, and setting @code{edebug-test-coverage} to @code{t}, when
|
|
|
901 the breakpoint is reached, the frequency data is looks like this:
|
|
|
902
|
|
|
903 @example
|
|
|
904 (defun fac (n)
|
|
|
905 (if (= n 0) (edebug))
|
|
444
|
906 ;#6 1 0 =5
|
|
428
|
907 (if (< 0 n)
|
|
444
|
908 ;#5 =
|
|
428
|
909 (* n (fac (1- n)))
|
|
444
|
910 ;# 5 0
|
|
428
|
911 1))
|
|
444
|
912 ;# 0
|
|
428
|
913 @end example
|
|
|
914
|
|
|
915 The comment lines show that @code{fac} has been called 6 times. The
|
|
|
916 first @code{if} statement has returned 5 times with the same result each
|
|
|
917 time, and the same is true for the condition on the second @code{if}.
|
|
|
918 The recursive call of @code{fac} has not returned at all.
|
|
|
919
|
|
|
920
|
|
|
921 @node The Outside Context
|
|
|
922 @subsection The Outside Context
|
|
|
923
|
|
|
924 Edebug tries to be transparent to the program you are debugging. In
|
|
|
925 addition, most evaluations you do within Edebug (see @ref{Edebug Eval})
|
|
|
926 occur in the same outside context which is temporarily restored for the
|
|
|
927 evaluation. But Edebug is not completely successful and this section
|
|
|
928 explains precisely how it fails. Edebug operation unavoidably alters
|
|
|
929 some data in XEmacs, and this can interfere with debugging certain
|
|
|
930 programs. Also notice that Edebug's protection against change of
|
|
|
931 outside data means that any side effects @emph{intended} by the user in
|
|
|
932 the course of debugging will be defeated.
|
|
|
933
|
|
|
934 @menu
|
|
|
935 * Checking Whether to Stop:: When Edebug decides what to do.
|
|
|
936 * Edebug Display Update:: When Edebug updates the display.
|
|
|
937 * Edebug Recursive Edit:: When Edebug stops execution.
|
|
|
938 @end menu
|
|
|
939
|
|
|
940
|
|
|
941 @node Checking Whether to Stop
|
|
|
942 @subsubsection Checking Whether to Stop
|
|
|
943
|
|
|
944 Whenever Edebug is entered just to think about whether to take some
|
|
|
945 action, it needs to save and restore certain data.
|
|
|
946
|
|
|
947 @itemize @bullet
|
|
444
|
948 @item
|
|
428
|
949 @code{max-lisp-eval-depth} and @code{max-specpdl-size} are both
|
|
|
950 incremented one time to reduce Edebug's impact on the stack.
|
|
|
951 You could, however, still run out of stack space when using Edebug.
|
|
|
952
|
|
444
|
953 @item
|
|
428
|
954 The state of keyboard macro execution is saved and restored. While
|
|
|
955 Edebug is active, @code{executing-macro} is bound to
|
|
|
956 @code{edebug-continue-kbd-macro}.
|
|
|
957
|
|
|
958 @end itemize
|
|
|
959
|
|
|
960
|
|
|
961 @node Edebug Display Update
|
|
|
962 @subsubsection Edebug Display Update
|
|
|
963
|
|
|
964 When Edebug needs to display something (e.g., in trace mode), it saves
|
|
|
965 the current window configuration from ``outside'' Edebug. When you exit
|
|
|
966 Edebug (by continuing the program), it restores the previous window
|
|
|
967 configuration.
|
|
|
968
|
|
|
969 XEmacs redisplays only when it pauses. Usually, when you continue
|
|
|
970 execution, the program comes back into Edebug at a breakpoint or after
|
|
|
971 stepping without pausing or reading input in between. In such cases,
|
|
|
972 XEmacs never gets a chance to redisplay the ``outside'' configuration.
|
|
|
973 What you see is the same window configuration as the last time Edebug
|
|
|
974 was active, with no interruption.
|
|
|
975
|
|
|
976 Entry to Edebug for displaying something also saves and restores the
|
|
|
977 following data, but some of these are deliberately not restored if an
|
|
|
978 error or quit signal occurs.
|
|
|
979
|
|
|
980 @itemize @bullet
|
|
444
|
981 @item
|
|
428
|
982 @cindex current buffer point and mark (Edebug)
|
|
|
983 Which buffer is current, and where point and mark are in the current
|
|
|
984 buffer are saved and restored.
|
|
|
985
|
|
444
|
986 @item
|
|
428
|
987 @cindex window configuration (Edebug)
|
|
|
988 @findex save-excursion (Edebug)
|
|
|
989 @vindex edebug-save-windows
|
|
|
990 The Edebug Display Update, is saved and restored if
|
|
|
991 @code{edebug-save-windows} is non-@code{nil}. It is not restored on
|
|
|
992 error or quit, but the outside selected window @emph{is} reselected even
|
|
444
|
993 on error or quit in case a @code{save-excursion} is active.
|
|
428
|
994 If the value of @code{edebug-save-windows} is a list, only the listed
|
|
|
995 windows are saved and restored.
|
|
|
996
|
|
|
997 The window start and horizontal scrolling of the source code buffer are
|
|
|
998 not restored, however, so that the display remains coherent.
|
|
|
999
|
|
|
1000 @item
|
|
|
1001 @vindex edebug-save-displayed-buffer-points
|
|
|
1002 The value of point in each displayed buffer is saved and restored if
|
|
|
1003 @code{edebug-save-displayed-buffer-points} is non-@code{nil}.
|
|
|
1004
|
|
|
1005 @item
|
|
|
1006 The variables @code{overlay-arrow-position} and
|
|
|
1007 @code{overlay-arrow-string} are saved and restored. So you can safely
|
|
|
1008 invoke Edebug from the recursive edit elsewhere in the same buffer.
|
|
|
1009
|
|
444
|
1010 @item
|
|
428
|
1011 @code{cursor-in-echo-area} is locally bound to @code{nil} so that
|
|
|
1012 the cursor shows up in the window.
|
|
|
1013
|
|
|
1014 @end itemize
|
|
|
1015
|
|
|
1016
|
|
|
1017 @node Edebug Recursive Edit
|
|
|
1018 @subsubsection Edebug Recursive Edit
|
|
|
1019
|
|
|
1020 When Edebug is entered and actually reads commands from the user, it
|
|
|
1021 saves (and later restores) these additional data:
|
|
|
1022
|
|
|
1023 @itemize @bullet
|
|
|
1024 @item
|
|
|
1025 The current match data, for whichever buffer was current.
|
|
|
1026
|
|
|
1027 @item
|
|
|
1028 @code{last-command}, @code{this-command}, @code{last-command-char},
|
|
|
1029 @code{last-input-char}, @code{last-input-event},
|
|
|
1030 @code{last-command-event},
|
|
|
1031 @code{last-event-frame}, @code{last-nonmenu-event}, and
|
|
|
1032 @code{track-mouse} . Commands used within Edebug do not affect these
|
|
|
1033 variables outside of Edebug.
|
|
|
1034
|
|
|
1035 The key sequence returned by @code{this-command-keys} is changed by
|
|
|
1036 executing commands within Edebug and there is no way to reset
|
|
|
1037 the key sequence from Lisp.
|
|
|
1038
|
|
|
1039 For Emacs 18, Edebug cannot save and restore the value of
|
|
|
1040 @code{unread-command-char}. Entering Edebug while this variable has
|
|
|
1041 a nontrivial value can interfere with execution of the program you are
|
|
|
1042 debugging.
|
|
|
1043
|
|
|
1044 @item
|
|
|
1045 Complex commands executed while in Edebug are added to the variable
|
|
|
1046 @code{command-history}. In rare cases this can alter execution.
|
|
|
1047
|
|
|
1048 @item
|
|
|
1049 Within Edebug, the recursion depth appears one deeper than the recursion
|
|
|
1050 depth outside Edebug. This is not true of the automatically updated
|
|
|
1051 evaluation list window.
|
|
|
1052
|
|
|
1053 @item
|
|
|
1054 @code{standard-output} and @code{standard-input} are bound to @code{nil}
|
|
|
1055 by the @code{recursive-edit}, but Edebug temporarily restores them during
|
|
|
1056 evaluations.
|
|
|
1057
|
|
444
|
1058 @item
|
|
428
|
1059 The state of keyboard macro definition is saved and restored. While
|
|
|
1060 Edebug is active, @code{defining-kbd-macro} is bound to
|
|
|
1061 @code{edebug-continue-kbd-macro}.
|
|
|
1062
|
|
|
1063 @end itemize
|
|
|
1064
|
|
|
1065
|
|
|
1066 @node Instrumenting Macro Calls
|
|
|
1067 @subsection Instrumenting Macro Calls
|
|
|
1068
|
|
|
1069 When Edebug instruments an expression that calls a Lisp macro, it needs
|
|
|
1070 additional advice to do the job properly. This is because there is no
|
|
|
1071 way to tell which subexpressions of the macro call may be evaluated.
|
|
|
1072 (Evaluation may occur explicitly in the macro body, or when the
|
|
|
1073 resulting expansion is evaluated, or any time later.) You must explain
|
|
|
1074 the format of macro call arguments by using @code{def-edebug-spec} to
|
|
|
1075 define an @dfn{Edebug specification} for each macro.
|
|
|
1076
|
|
444
|
1077 @defmac def-edebug-spec macro specification
|
|
428
|
1078 Specify which expressions of a call to macro @var{macro} are forms to be
|
|
|
1079 evaluated. For simple macros, the @var{specification} often looks very
|
|
|
1080 similar to the formal argument list of the macro definition, but
|
|
|
1081 specifications are much more general than macro arguments.
|
|
|
1082
|
|
|
1083 The @var{macro} argument may actually be any symbol, not just a macro
|
|
|
1084 name.
|
|
|
1085
|
|
|
1086 Unless you are using Emacs 19 or XEmacs, this macro is only defined
|
|
|
1087 in Edebug, so you may want to use the following which is equivalent:
|
|
|
1088 @code{(put '@var{macro} 'edebug-form-spec '@var{specification})}
|
|
444
|
1089 @end defmac
|
|
428
|
1090
|
|
|
1091 Here is a simple example that defines the specification for the
|
|
|
1092 @code{for} macro described in the XEmacs Lisp Reference Manual, followed
|
|
|
1093 by an alternative, equivalent specification.
|
|
|
1094
|
|
|
1095 @example
|
|
|
1096 (def-edebug-spec for
|
|
|
1097 (symbolp "from" form "to" form "do" &rest form))
|
|
|
1098
|
|
|
1099 (def-edebug-spec for
|
|
|
1100 (symbolp ['from form] ['to form] ['do body]))
|
|
|
1101 @end example
|
|
|
1102
|
|
|
1103 Here is a table of the possibilities for @var{specification} and how each
|
|
|
1104 directs processing of arguments.
|
|
|
1105
|
|
|
1106 @table @bullet
|
|
|
1107
|
|
|
1108 @item @code{t}
|
|
|
1109 All arguments are instrumented for evaluation.
|
|
|
1110
|
|
|
1111 @item @code{0}
|
|
|
1112 None of the arguments is instrumented.
|
|
|
1113
|
|
|
1114 @item a symbol
|
|
|
1115 The symbol must have an Edebug specification which is used instead.
|
|
|
1116 This indirection is repeated until another kind of specification is
|
|
|
1117 found. This allows you to inherit the specification for another macro.
|
|
|
1118
|
|
|
1119 @item a list
|
|
|
1120 The elements of the list describe the types of the arguments of a
|
|
|
1121 calling form. The possible elements of a specification list are
|
|
|
1122 described in the following sections.
|
|
|
1123 @end table
|
|
|
1124
|
|
|
1125 @menu
|
|
|
1126 * Specification List:: How to specify complex patterns of evaluation.
|
|
|
1127 * Backtracking:: What Edebug does when matching fails.
|
|
|
1128 * Debugging Backquote:: Debugging Backquote
|
|
|
1129 * Specification Examples:: To help understand specifications.
|
|
|
1130 @end menu
|
|
|
1131
|
|
|
1132
|
|
|
1133 @node Specification List
|
|
|
1134 @subsubsection Specification List
|
|
|
1135
|
|
|
1136 @cindex Edebug specification list
|
|
|
1137 A @dfn{specification list} is required for an Edebug specification if
|
|
|
1138 some arguments of a macro call are evaluated while others are not. Some
|
|
|
1139 elements in a specification list match one or more arguments, but others
|
|
|
1140 modify the processing of all following elements. The latter, called
|
|
|
1141 @dfn{keyword specifications}, are symbols beginning with @samp{@code{&}}
|
|
|
1142 (e.g. @code{&optional}).
|
|
|
1143
|
|
|
1144 A specification list may contain sublists which match arguments that are
|
|
|
1145 themselves lists, or it may contain vectors used for grouping. Sublists
|
|
|
1146 and groups thus subdivide the specification list into a hierarchy of
|
|
|
1147 levels. Keyword specifications only apply to the remainder of the
|
|
|
1148 sublist or group they are contained in and there is an implicit grouping
|
|
|
1149 around a keyword specification and all following elements in the
|
|
|
1150 sublist or group.
|
|
|
1151
|
|
|
1152 If a specification list fails
|
|
|
1153 at some level, then backtracking may be invoked to find some alternative
|
|
|
1154 at a higher level, or if no alternatives remain, an error will be
|
|
|
1155 signaled. See @ref{Backtracking} for more details.
|
|
|
1156
|
|
|
1157 Edebug specifications provide at least the power of regular expression
|
|
|
1158 matching. Some context-free constructs are also supported: the matching
|
|
|
1159 of sublists with balanced parentheses, recursive processing of forms,
|
|
|
1160 and recursion via indirect specifications.
|
|
|
1161
|
|
|
1162 Each element of a specification list may be one of the following, with
|
|
|
1163 the corresponding type of argument:
|
|
|
1164
|
|
|
1165 @table @code
|
|
|
1166
|
|
|
1167 @item sexp
|
|
|
1168 A single unevaluated expression.
|
|
|
1169
|
|
|
1170 @item form
|
|
|
1171 A single evaluated expression, which is instrumented.
|
|
|
1172
|
|
|
1173 @item place
|
|
|
1174 @findex edebug-unwrap
|
|
|
1175 A place as in the Common Lisp @code{setf} place argument. It will be
|
|
|
1176 instrumented just like a form, but the macro is expected to strip the
|
|
|
1177 instrumentation. Two functions, @code{edebug-unwrap} and
|
|
|
1178 @code{edebug-unwrap*}, are provided to strip the instrumentation one
|
|
|
1179 level or recursively at all levels.
|
|
|
1180
|
|
|
1181 @item body
|
|
|
1182 Short for @code{&rest form}. See @code{&rest} below.
|
|
|
1183
|
|
|
1184 @item function-form
|
|
|
1185 A function form: either a quoted function symbol, a quoted lambda expression,
|
|
|
1186 or a form (that should evaluate to a function symbol or lambda
|
|
|
1187 expression). This is useful when function arguments might be quoted
|
|
|
1188 with @code{quote} rather than @code{function} since the body of a lambda
|
|
|
1189 expression will be instrumented either way.
|
|
|
1190
|
|
|
1191 @item lambda-expr
|
|
|
1192 An unquoted anonymous lambda expression.
|
|
|
1193
|
|
|
1194 @item &optional
|
|
|
1195 @cindex &optional (Edebug)
|
|
|
1196 All following elements in the specification list are optional; as soon
|
|
444
|
1197 as one does not match, Edebug stops matching at this level.
|
|
428
|
1198
|
|
|
1199 To make just a few elements optional followed by non-optional elements,
|
|
|
1200 use @code{[&optional @var{specs}@dots{}]}. To specify that several
|
|
|
1201 elements should all succeed together, use @code{&optional
|
|
|
1202 [@var{specs}@dots{}]}. See the @code{defun} example below.
|
|
|
1203
|
|
|
1204 @item &rest
|
|
|
1205 @cindex &rest (Edebug)
|
|
|
1206 All following elements in the specification list are repeated zero or
|
|
|
1207 more times. All the elements need not match in the last repetition,
|
|
|
1208 however.
|
|
|
1209
|
|
|
1210 To repeat only a few elements, use @code{[&rest @var{specs}@dots{}]}.
|
|
|
1211 To specify all elements must match on every repetition, use @code{&rest
|
|
|
1212 [@var{specs}@dots{}]}.
|
|
|
1213
|
|
|
1214 @item &or
|
|
|
1215 @cindex &or (Edebug)
|
|
|
1216 Each of the following elements in the specification list is an
|
|
|
1217 alternative, processed left to right until one matches. One of the
|
|
|
1218 alternatives must match otherwise the @code{&or} specification fails.
|
|
|
1219
|
|
|
1220 Each list element following @code{&or} is a single alternative even if
|
|
|
1221 it is a keyword specification. (This breaks the implicit grouping rule.)
|
|
|
1222 To group two or more list elements as a single alternative, enclose them
|
|
|
1223 in @code{[@dots{}]}.
|
|
|
1224
|
|
|
1225 @item ¬
|
|
|
1226 @cindex ¬ (Edebug)
|
|
|
1227 Each of the following elements is matched as alternatives as if by using
|
|
|
1228 @code{&or}, but if any of them match, the specification fails. If none
|
|
|
1229 of them match, nothing is matched, but the @code{¬} specification
|
|
|
1230 succeeds.
|
|
|
1231
|
|
444
|
1232 @item &define
|
|
428
|
1233 @cindex &define (Edebug)
|
|
|
1234 Indicates that the specification is for a defining form. The defining
|
|
|
1235 form itself is not instrumented (i.e. Edebug does not stop before and
|
|
|
1236 after the defining form), but forms inside it typically will be
|
|
|
1237 instrumented. The @code{&define} keyword should be the first element in
|
|
|
1238 a list specification.
|
|
|
1239
|
|
|
1240 Additional specifications that may only appear after @code{&define} are
|
|
|
1241 described here. See the @code{defun} example below.
|
|
|
1242
|
|
|
1243 @table @code
|
|
|
1244
|
|
|
1245 @item name
|
|
444
|
1246 The argument, a symbol, is the name of the defining form.
|
|
428
|
1247 But a defining form need not be named at all, in which
|
|
|
1248 case a unique name will be created for it.
|
|
|
1249
|
|
|
1250 The @code{name} specification may be used more than once in the
|
|
|
1251 specification and each subsequent use will append the corresponding
|
|
|
1252 symbol argument to the previous name with @samp{@code{@@}} between them.
|
|
|
1253 This is useful for generating unique but meaningful names for
|
|
|
1254 definitions such as @code{defadvice} and @code{defmethod}.
|
|
|
1255
|
|
|
1256 @item :name
|
|
|
1257 The element following @code{:name} should be a symbol; it is used as an
|
|
|
1258 additional name component for the definition. This is useful to add a
|
|
|
1259 unique, static component to the name of the definition. It may be used
|
|
|
1260 more than once. No argument is matched.
|
|
|
1261
|
|
|
1262 @item arg
|
|
|
1263 The argument, a symbol, is the name of an argument of the defining form.
|
|
|
1264 However, lambda list keywords (symbols starting with @samp{@code{&}})
|
|
|
1265 are not allowed. See @code{lambda-list} and the example below.
|
|
|
1266
|
|
|
1267 @item lambda-list
|
|
|
1268 @cindex lambda-list (Edebug)
|
|
|
1269 This matches the whole argument list of an XEmacs Lisp lambda
|
|
|
1270 expression, which is a list of symbols and the keywords
|
|
|
1271 @code{&optional} and @code{&rest}
|
|
|
1272
|
|
|
1273 @item def-body
|
|
|
1274 The argument is the body of code in a definition. This is like
|
|
|
1275 @code{body}, described above, but a definition body must be instrumented
|
|
|
1276 with a different Edebug call that looks up information associated with
|
|
|
1277 the definition. Use @code{def-body} for the highest level list of forms
|
|
|
1278 within the definition.
|
|
|
1279
|
|
|
1280 @item def-form
|
|
|
1281 The argument is a single, highest-level form in a definition. This is
|
|
|
1282 like @code{def-body}, except use this to match a single form rather than
|
|
|
1283 a list of forms. As a special case, @code{def-form} also means that
|
|
|
1284 tracing information is not output when the form is executed. See the
|
|
|
1285 @code{interactive} example below.
|
|
|
1286
|
|
|
1287 @end table
|
|
|
1288
|
|
|
1289 @item nil
|
|
|
1290 This is successful when there are no more arguments to match at the
|
|
|
1291 current argument list level; otherwise it fails. See sublist
|
|
|
1292 specifications and the backquote example below.
|
|
|
1293
|
|
|
1294 @item gate
|
|
|
1295 @cindex preventing backtracking
|
|
|
1296 No argument is matched but backtracking through the gate is disabled
|
|
|
1297 while matching the remainder of the specifications at this level. This
|
|
|
1298 is primarily used to generate more specific syntax error messages. See
|
|
|
1299 @ref{Backtracking} for more details. Also see the @code{let} example
|
|
|
1300 below.
|
|
|
1301
|
|
|
1302 @item @var{other-symbol}
|
|
|
1303 @cindex indirect specifications
|
|
|
1304 Any other symbol in a specification list may be a predicate or an
|
|
|
1305 indirect specification.
|
|
|
1306
|
|
|
1307 If the symbol has an Edebug specification, this @dfn{indirect
|
|
|
1308 specification} should be either a list specification that is used in
|
|
|
1309 place of the symbol, or a function that is called to process the
|
|
|
1310 arguments. The specification may be defined with @code{def-edebug-spec}
|
|
|
1311 just as for macros. See the @code{defun} example below.
|
|
|
1312
|
|
|
1313 Otherwise, the symbol should be a predicate. The predicate is called
|
|
|
1314 with the argument and the specification fails if the predicate fails.
|
|
|
1315 The argument is not instrumented.
|
|
|
1316
|
|
|
1317 @findex keywordp
|
|
|
1318 @findex lambda-list-keywordp
|
|
|
1319 Predicates that may be used include: @code{symbolp}, @code{integerp},
|
|
|
1320 @code{stringp}, @code{vectorp}, @code{atom} (which matches a number,
|
|
|
1321 string, symbol, or vector), @code{keywordp}, and
|
|
|
1322 @code{lambda-list-keywordp}. The last two, defined in @file{edebug.el},
|
|
|
1323 test whether the argument is a symbol starting with @samp{@code{:}} and
|
|
|
1324 @samp{@code{&}} respectively.
|
|
|
1325
|
|
|
1326 @item [@var{elements}@dots{}]
|
|
|
1327 @cindex [@dots{}] (Edebug)
|
|
|
1328 Rather than matching a vector argument, a vector treats
|
|
|
1329 the @var{elements} as a single @dfn{group specification}.
|
|
|
1330
|
|
|
1331 @item "@var{string}"
|
|
|
1332 The argument should be a symbol named @var{string}. This specification
|
|
|
1333 is equivalent to the quoted symbol, @code{'@var{symbol}}, where the name
|
|
|
1334 of @var{symbol} is the @var{string}, but the string form is preferred.
|
|
|
1335
|
|
|
1336 @item '@var{symbol} @r{or} (quote @var{symbol})
|
|
|
1337 The argument should be the symbol @var{symbol}. But use a string
|
|
|
1338 specification instead.
|
|
|
1339
|
|
|
1340 @item (vector @var{elements}@dots{})
|
|
|
1341 The argument should be a vector whose elements must match the
|
|
|
1342 @var{elements} in the specification. See the backquote example below.
|
|
|
1343
|
|
|
1344 @item (@var{elements}@dots{})
|
|
|
1345 Any other list is a @dfn{sublist specification} and the argument must be
|
|
|
1346 a list whose elements match the specification @var{elements}.
|
|
|
1347
|
|
|
1348 @cindex dotted lists (Edebug)
|
|
|
1349 A sublist specification may be a dotted list and the corresponding list
|
|
|
1350 argument may then be a dotted list. Alternatively, the last cdr of a
|
|
|
1351 dotted list specification may be another sublist specification (via a
|
|
|
1352 grouping or an indirect specification, e.g. @code{(spec . [(more
|
|
|
1353 specs@dots{})])}) whose elements match the non-dotted list arguments.
|
|
|
1354 This is useful in recursive specifications such as in the backquote
|
|
|
1355 example below. Also see the description of a @code{nil} specification
|
|
|
1356 above for terminating such recursion.
|
|
|
1357
|
|
|
1358 Note that a sublist specification of the form @code{(specs . nil)}
|
|
|
1359 means the same as @code{(specs)}, and @code{(specs .
|
|
|
1360 (sublist-elements@dots{}))} means the same as @code{(specs
|
|
|
1361 sublist-elements@dots{})}.
|
|
|
1362
|
|
|
1363 @end table
|
|
|
1364
|
|
|
1365 @c Need to document extensions with &symbol and :symbol
|
|
|
1366
|
|
|
1367 @node Backtracking
|
|
|
1368 @subsubsection Backtracking
|
|
|
1369
|
|
|
1370 @cindex backtracking
|
|
|
1371 @cindex syntax error (Edebug)
|
|
|
1372 If a specification fails to match at some point, this does not
|
|
|
1373 necessarily mean a syntax error will be signaled; instead,
|
|
|
1374 @dfn{backtracking} will take place until all alternatives have been
|
|
|
1375 exhausted. Eventually every element of the argument list must be
|
|
|
1376 matched by some element in the specification, and every required element
|
|
|
1377 in the specification must match some argument.
|
|
|
1378
|
|
|
1379 Backtracking is disabled for the remainder of a sublist or group when
|
|
|
1380 certain conditions occur, described below. Backtracking is reenabled
|
|
|
1381 when a new alternative is established by @code{&optional}, @code{&rest},
|
|
|
1382 or @code{&or}. It is also reenabled initially when processing a
|
|
|
1383 sublist or group specification or an indirect specification.
|
|
|
1384
|
|
|
1385 You might want to disable backtracking to commit to some alternative so
|
|
|
1386 that Edebug can provide a more specific syntax error message. Normally,
|
|
|
1387 if no alternative matches, Edebug reports that none matched, but if one
|
|
|
1388 alternative is committed to, Edebug can report how it failed to match.
|
|
|
1389
|
|
|
1390 First, backtracking is disabled while matching any of the form
|
|
|
1391 specifications (i.e. @code{form}, @code{body}, @code{def-form}, and
|
|
|
1392 @code{def-body}). These specifications will match any form so any error
|
|
|
1393 must be in the form itself rather than at a higher level.
|
|
|
1394
|
|
|
1395 Second, backtracking is disabled after successfully matching a quoted
|
|
|
1396 symbol or string specification, since this usually indicates a
|
|
|
1397 recognized construct. If you have a set of alternative constructs that
|
|
|
1398 all begin with the same symbol, you can usually work around this
|
|
|
1399 constraint by factoring the symbol out of the alternatives, e.g.,
|
|
|
1400 @code{["foo" &or [first case] [second case] ...]}.
|
|
|
1401
|
|
|
1402 Third, backtracking may be explicitly disabled by using the
|
|
|
1403 @code{gate} specification. This is useful when you know that
|
|
|
1404 no higher alternatives may apply.
|
|
|
1405
|
|
|
1406
|
|
|
1407 @node Debugging Backquote
|
|
|
1408 @subsubsection Debugging Backquote
|
|
|
1409
|
|
|
1410 @findex ` (Edebug)
|
|
|
1411 @cindex backquote (Edebug)
|
|
|
1412 Backquote (@kbd{`}) is a macro that results in an expression that may or
|
|
|
1413 may not be evaluated. It is often used to simplify the definition of a
|
|
|
1414 macro to return an expression that is evaluated, but Edebug does not know
|
|
|
1415 when this is the case. However, the forms inside unquotes (@code{,} and
|
|
|
1416 @code{,@@}) are evaluated and Edebug instruments them.
|
|
|
1417
|
|
|
1418 Nested backquotes are supported by Edebug, but there is a limit on the
|
|
|
1419 support of quotes inside of backquotes. Quoted forms (with @code{'})
|
|
|
1420 are not normally evaluated, but if the quoted form appears immediately
|
|
|
1421 within @code{,} and @code{,@@} forms, Edebug treats this as a backquoted
|
|
|
1422 form at the next higher level (even if there is not a next higher level
|
|
|
1423 - this is difficult to fix).
|
|
|
1424
|
|
|
1425 @findex edebug-`
|
|
|
1426 If the backquoted forms happen to be code intended to be evaluated, you
|
|
|
1427 can have Edebug instrument them by using @code{edebug-`} instead of the
|
|
|
1428 regular @code{`}. Unquoted forms can always appear inside
|
|
|
1429 @code{edebug-`} anywhere a form is normally allowed. But @code{(,
|
|
|
1430 @var{form})} may be used in two other places specially recognized by
|
|
|
1431 Edebug: wherever a predicate specification would match, and at the head
|
|
|
1432 of a list form in place of a function name or lambda expression. The
|
|
|
1433 @var{form} inside a spliced unquote, @code{(,@@ @var{form})}, will be
|
|
|
1434 wrapped, but the unquote form itself will not be wrapped since this
|
|
|
1435 would interfere with the splicing.
|
|
|
1436
|
|
|
1437 There is one other complication with using @code{edebug-`}. If the
|
|
|
1438 @code{edebug-`} call is in a macro and the macro may be called from code
|
|
|
1439 that is also instrumented, and if unquoted forms contain any macro
|
|
|
1440 arguments bound to instrumented forms, then you should modify the
|
|
|
1441 specification for the macro as follows: the specifications for those
|
|
|
1442 arguments must use @code{def-form} instead of @code{form}. (This is to
|
|
|
1443 reestablish the Edebugging context for those external forms.)
|
|
|
1444
|
|
444
|
1445 For example, the @code{for} macro
|
|
428
|
1446 @c (@pxref{Problems with Macros}) @c in XEmacs Lisp Reference Manual
|
|
|
1447 (@pxref{Problems with Macros,,,, XEmacs Lisp Reference Manual}) @c Edebug Doc
|
|
|
1448 is shown here but with @code{edebug-`}
|
|
|
1449 substituted for regular @code{`}.
|
|
|
1450
|
|
|
1451 @example
|
|
|
1452 (defmacro inc (var)
|
|
|
1453 (list 'setq var (list '1+ var)))
|
|
|
1454
|
|
|
1455 (defmacro for (var from init to final do &rest body)
|
|
|
1456 (let ((tempvar (make-symbol "max")))
|
|
|
1457 (edebug-` (let (((, var) (, init))
|
|
|
1458 ((, tempvar) (, final)))
|
|
|
1459 (while (<= (, var) (, tempvar))
|
|
|
1460 (,@ body)
|
|
|
1461 (inc (, var)))))))
|
|
|
1462 @end example
|
|
|
1463
|
|
|
1464 Here is the corresponding modified Edebug specification and some code
|
|
|
1465 that calls the macro:
|
|
|
1466
|
|
|
1467 @example
|
|
|
1468 (def-edebug-spec for
|
|
|
1469 (symbolp "from" def-form "to" def-form "do" &rest def-form))
|
|
|
1470
|
|
|
1471 (let ((n 5))
|
|
|
1472 (for i from n to (* n (+ n 1)) do
|
|
|
1473 (message "%s" i)))
|
|
|
1474 @end example
|
|
|
1475
|
|
|
1476 After instrumenting the @code{for} macro and the macro call, Edebug
|
|
|
1477 first steps to the beginning of the macro call, then into the macro
|
|
|
1478 body, then through each of the unquoted expressions in the backquote
|
|
|
1479 showing the expressions that will be embedded in the backquote form.
|
|
|
1480 Then when the macro expansion is evaluated, Edebug will step through the
|
|
|
1481 @code{let} form and each time it gets to an unquoted form, it will jump
|
|
|
1482 back to an argument of the macro call to step through that expression.
|
|
|
1483 Finally stepping will continue after the macro call. Even more
|
|
|
1484 convoluted execution paths may result when using anonymous functions.
|
|
|
1485
|
|
|
1486 @vindex edebug-unwrap-results
|
|
|
1487 When the result of an expression is an instrumented expression, it is
|
|
|
1488 difficult to see the expression inside the instrumentation. So
|
|
|
1489 you may want to set the option @code{edebug-unwrap-results} to a
|
|
|
1490 non-@code{nil} value while debugging such expressions, but it would slow
|
|
|
1491 Edebug down to always do this.
|
|
|
1492
|
|
|
1493
|
|
|
1494 @node Specification Examples
|
|
|
1495 @subsubsection Specification Examples
|
|
|
1496
|
|
|
1497 Here we provide several examples of Edebug specifications to show
|
|
|
1498 many of its capabilities.
|
|
|
1499
|
|
|
1500 A @code{let} special form has a sequence of bindings and a body. Each
|
|
|
1501 of the bindings is either a symbol or a sublist with a symbol and
|
|
|
1502 optional value. In the specification below, notice the @code{gate}
|
|
|
1503 inside of the sublist to prevent backtracking.
|
|
|
1504
|
|
|
1505 @example
|
|
|
1506 (def-edebug-spec let
|
|
|
1507 ((&rest
|
|
|
1508 &or symbolp (gate symbolp &optional form))
|
|
|
1509 body))
|
|
|
1510 @end example
|
|
|
1511
|
|
|
1512 Edebug uses the following specifications for @code{defun} and
|
|
|
1513 @code{defmacro} and the associated argument list and @code{interactive}
|
|
|
1514 specifications. It is necessary to handle the expression argument of an
|
|
|
1515 interactive form specially since it is actually evaluated outside of the
|
|
|
1516 function body.
|
|
|
1517
|
|
|
1518 @example
|
|
|
1519 (def-edebug-spec defmacro defun) ; @r{Indirect ref to @code{defun} spec}
|
|
444
|
1520 (def-edebug-spec defun
|
|
|
1521 (&define name lambda-list
|
|
428
|
1522 [&optional stringp] ; @r{Match the doc string, if present.}
|
|
|
1523 [&optional ("interactive" interactive)]
|
|
|
1524 def-body))
|
|
|
1525
|
|
|
1526 (def-edebug-spec lambda-list
|
|
|
1527 (([&rest arg]
|
|
|
1528 [&optional ["&optional" arg &rest arg]]
|
|
|
1529 &optional ["&rest" arg]
|
|
|
1530 )))
|
|
|
1531
|
|
|
1532 (def-edebug-spec interactive
|
|
|
1533 (&optional &or stringp def-form)) ; @r{Notice: @code{def-form}}
|
|
|
1534 @end example
|
|
|
1535
|
|
|
1536 The specification for backquote below illustrates how to match
|
|
|
1537 dotted lists and use @code{nil} to terminate recursion. It also
|
|
|
1538 illustrates how components of a vector may be matched. (The actual
|
|
|
1539 specification provided by Edebug does not support dotted lists because
|
|
|
1540 doing so causes very deep recursion that could fail.)
|
|
|
1541
|
|
|
1542 @example
|
|
|
1543 (def-edebug-spec ` (backquote-form)) ;; alias just for clarity
|
|
|
1544
|
|
|
1545 (def-edebug-spec backquote-form
|
|
|
1546 (&or ([&or "," ",@@"] &or ("quote" backquote-form) form)
|
|
|
1547 (backquote-form . [&or nil backquote-form])
|
|
|
1548 (vector &rest backquote-form)
|
|
|
1549 sexp))
|
|
|
1550 @end example
|
|
|
1551
|
|
|
1552
|
|
|
1553 @node Edebug Options
|
|
|
1554 @subsection Edebug Options
|
|
|
1555
|
|
|
1556 These options affect the behavior of Edebug:
|
|
|
1557
|
|
|
1558 @defopt edebug-setup-hook
|
|
|
1559 Functions to call before Edebug is used. Each time it is set to a new
|
|
|
1560 value, Edebug will call those functions once and then
|
|
|
1561 @code{edebug-setup-hook} is reset to @code{nil}. You could use this to
|
|
|
1562 load up Edebug specifications associated with a package you are using
|
|
|
1563 but only when you also use Edebug.
|
|
|
1564 See @ref{Instrumenting}.
|
|
|
1565 @end defopt
|
|
|
1566
|
|
|
1567 @defopt edebug-all-defs
|
|
|
1568 If non-@code{nil}, normal evaluation of any defining forms (e.g.
|
|
|
1569 @code{defun} and @code{defmacro}) will instrument them for Edebug. This
|
|
|
1570 applies to @code{eval-defun}, @code{eval-region}, and
|
|
|
1571 @code{eval-current-buffer}.
|
|
|
1572
|
|
|
1573 Use the command @kbd{M-x edebug-all-defs} to toggle the value of
|
|
|
1574 this variable. You may want to make this variable local to each
|
|
|
1575 buffer by calling @code{(make-local-variable 'edebug-all-defs)} in your
|
|
|
1576 @code{emacs-lisp-mode-hook}.
|
|
|
1577 See @ref{Instrumenting}.
|
|
|
1578 @end defopt
|
|
|
1579
|
|
|
1580 @defopt edebug-all-forms
|
|
|
1581 If non-@code{nil}, normal evaluation of any forms by @code{eval-defun},
|
|
|
1582 @code{eval-region}, and @code{eval-current-buffer} will instrument them
|
|
|
1583 for Edebug.
|
|
|
1584
|
|
|
1585 Use the command @kbd{M-x edebug-all-forms} to toggle the value of this
|
|
|
1586 option.
|
|
|
1587 See @ref{Instrumenting}.
|
|
|
1588 @end defopt
|
|
|
1589
|
|
|
1590 @defopt edebug-save-windows
|
|
|
1591 If non-@code{nil}, save and restore window configuration on Edebug
|
|
|
1592 calls. It takes some time to do this, so if your program does not care
|
|
|
1593 what happens to data about windows, you may want to set this variable to
|
|
|
1594 @code{nil}.
|
|
|
1595
|
|
|
1596 If the value is a list, only the listed windows are saved and
|
|
444
|
1597 restored.
|
|
428
|
1598
|
|
|
1599 @kbd{M-x edebug-toggle-save-windows} may be used to change this variable.
|
|
|
1600 This command is bound to @kbd{W} in source code buffers.
|
|
|
1601 See @ref{Edebug Display Update}.
|
|
|
1602 @end defopt
|
|
|
1603
|
|
|
1604 @defopt edebug-save-displayed-buffer-points
|
|
|
1605 If non-@code{nil}, save and restore point in all displayed buffers.
|
|
|
1606 This is necessary if you are debugging code that changes the point of a
|
|
|
1607 buffer which is displayed in a non-selected window. If Edebug or the
|
|
|
1608 user then selects the window, the buffer's point will be changed to the
|
|
|
1609 window's point.
|
|
|
1610
|
|
|
1611 This is an expensive operation since it visits each window and therefore
|
|
|
1612 each displayed buffer twice for each Edebug activation, so it is best to
|
|
|
1613 avoid it if you can.
|
|
|
1614 See @ref{Edebug Display Update}.
|
|
|
1615 @end defopt
|
|
|
1616
|
|
|
1617
|
|
|
1618 @defopt edebug-initial-mode
|
|
|
1619 If this variable is non-@code{nil}, it specifies the initial execution
|
|
|
1620 mode for Edebug when it is first activated. Possible values are
|
|
|
1621 @code{step}, @code{next}, @code{go}, @code{Go-nonstop}, @code{trace},
|
|
|
1622 @code{Trace-fast}, @code{continue}, and @code{Continue-fast}.
|
|
|
1623
|
|
444
|
1624 The default value is @code{step}.
|
|
428
|
1625 See @ref{Edebug Execution Modes}.
|
|
|
1626 @end defopt
|
|
|
1627
|
|
|
1628 @defopt edebug-trace
|
|
|
1629 @findex edebug-print-trace-before
|
|
|
1630 @findex edebug-print-trace-after
|
|
|
1631 Non-@code{nil} means display a trace of function entry and exit.
|
|
|
1632 Tracing output is displayed in a buffer named @samp{*edebug-trace*}, one
|
|
444
|
1633 function entry or exit per line, indented by the recursion level.
|
|
428
|
1634
|
|
444
|
1635 The default value is @code{nil}.
|
|
428
|
1636
|
|
|
1637 Also see @code{edebug-tracing}.
|
|
|
1638 See @ref{Tracing}.
|
|
|
1639 @end defopt
|
|
|
1640
|
|
444
|
1641 @defopt edebug-test-coverage
|
|
428
|
1642 If non-@code{nil}, Edebug tests coverage of all expressions debugged.
|
|
|
1643 This is done by comparing the result of each expression
|
|
|
1644 with the previous result. Coverage is considered OK if two different
|
|
|
1645 results are found. So to sufficiently test the coverage of your code,
|
|
|
1646 try to execute it under conditions that evaluate all expressions more
|
|
|
1647 than once, and produce different results for each expression.
|
|
|
1648
|
|
|
1649 Use @kbd{M-x edebug-display-freq-count} to display the frequency count
|
|
|
1650 and coverage information for a definition.
|
|
|
1651 See @ref{Coverage Testing}.
|
|
|
1652 @end defopt
|
|
|
1653
|
|
444
|
1654 @defopt edebug-continue-kbd-macro
|
|
428
|
1655 If non-@code{nil}, continue defining or executing any keyboard macro
|
|
|
1656 that is executing outside of Edebug. Use this with caution since it is not
|
|
|
1657 debugged.
|
|
|
1658 See @ref{Edebug Execution Modes}.
|
|
|
1659 @end defopt
|
|
|
1660
|
|
|
1661 @defopt edebug-print-length
|
|
|
1662 If non-@code{nil}, bind @code{print-length} to this while printing
|
|
|
1663 results in Edebug. The default value is @code{50}.
|
|
|
1664 See @ref{Printing in Edebug}.
|
|
|
1665 @end defopt
|
|
|
1666
|
|
444
|
1667 @defopt edebug-print-level
|
|
428
|
1668 If non-@code{nil}, bind @code{print-level} to this while printing
|
|
|
1669 results in Edebug. The default value is @code{50}.
|
|
|
1670 @end defopt
|
|
|
1671
|
|
444
|
1672 @defopt edebug-print-circle
|
|
428
|
1673 If non-@code{nil}, bind @code{print-circle} to this while printing
|
|
|
1674 results in Edebug. The default value is @code{nil}.
|
|
|
1675 @end defopt
|
|
|
1676
|
|
|
1677 @defopt edebug-on-error
|
|
|
1678 @code{debug-on-error} is bound to this while Edebug is active.
|
|
|
1679 See @ref{Trapping Errors}.
|
|
|
1680 @end defopt
|
|
|
1681
|
|
|
1682 @defopt edebug-on-quit
|
|
|
1683 @code{debug-on-quit} is bound to this while Edebug is active.
|
|
|
1684 See @ref{Trapping Errors}.
|
|
|
1685 @end defopt
|
|
|
1686
|
|
|
1687 @defopt edebug-unwrap-results
|
|
|
1688 Non-@code{nil} if Edebug should unwrap results of expressions.
|
|
|
1689 This is useful when debugging macros where the results of expressions
|
|
|
1690 are instrumented expressions. But don't do this when results might be
|
|
|
1691 circular or an infinite loop will result.
|
|
|
1692 See @ref{Debugging Backquote}.
|
|
|
1693 @end defopt
|
|
|
1694
|
|
|
1695 @defopt edebug-global-break-condition
|
|
|
1696 If non-@code{nil}, an expression to test for at every stop point.
|
|
444
|
1697 If the result is non-@code{nil}, then break. Errors are ignored.
|
|
428
|
1698 See @ref{Global Break Condition}.
|
|
|
1699 @end defopt
|
