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