Mercurial > emacs
annotate lispref/debugging.texi @ 21974:42b308d86213
(report-emacs-bug): After reinserting
the signature, leave point before it.
author | Richard M. Stallman <rms@gnu.org> |
---|---|
date | Thu, 07 May 1998 06:31:31 +0000 |
parents | 90da2489c498 |
children | d4ac295a98b3 |
rev | line source |
---|---|
6558 | 1 @c -*-texinfo-*- |
2 @c This is part of the GNU Emacs Lisp Reference Manual. | |
21007
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
3 @c Copyright (C) 1990, 1991, 1992, 1993, 1994, 1998 Free Software Foundation, Inc. |
6558 | 4 @c See the file elisp.texi for copying conditions. |
5 @setfilename ../info/debugging | |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
6 @node Debugging, Read and Print, Advising, Top |
6558 | 7 @chapter Debugging Lisp Programs |
8 | |
9 There are three ways to investigate a problem in an Emacs Lisp program, | |
10 depending on what you are doing with the program when the problem appears. | |
11 | |
12 @itemize @bullet | |
13 @item | |
14 If the problem occurs when you run the program, you can use a Lisp | |
15 debugger (either the default debugger or Edebug) to investigate what is | |
16 happening during execution. | |
17 | |
18 @item | |
19 If the problem is syntactic, so that Lisp cannot even read the program, | |
20 you can use the Emacs facilities for editing Lisp to localize it. | |
21 | |
22 @item | |
23 If the problem occurs when trying to compile the program with the byte | |
24 compiler, you need to know how to examine the compiler's input buffer. | |
25 @end itemize | |
26 | |
27 @menu | |
28 * Debugger:: How the Emacs Lisp debugger is implemented. | |
29 * Syntax Errors:: How to find syntax errors. | |
30 * Compilation Errors:: How to find errors that show up in byte compilation. | |
31 * Edebug:: A source-level Emacs Lisp debugger. | |
32 @end menu | |
33 | |
34 Another useful debugging tool is the dribble file. When a dribble | |
35 file is open, Emacs copies all keyboard input characters to that file. | |
36 Afterward, you can examine the file to find out what input was used. | |
37 @xref{Terminal Input}. | |
38 | |
39 For debugging problems in terminal descriptions, the | |
40 @code{open-termscript} function can be useful. @xref{Terminal Output}. | |
41 | |
42 @node Debugger | |
43 @section The Lisp Debugger | |
44 @cindex debugger | |
45 @cindex Lisp debugger | |
46 @cindex break | |
47 | |
48 The @dfn{Lisp debugger} provides the ability to suspend evaluation of | |
49 a form. While evaluation is suspended (a state that is commonly known | |
50 as a @dfn{break}), you may examine the run time stack, examine the | |
51 values of local or global variables, or change those values. Since a | |
52 break is a recursive edit, all the usual editing facilities of Emacs are | |
53 available; you can even run programs that will enter the debugger | |
54 recursively. @xref{Recursive Editing}. | |
55 | |
56 @menu | |
57 * Error Debugging:: Entering the debugger when an error happens. | |
58 * Infinite Loops:: Stopping and debugging a program that doesn't exit. | |
59 * Function Debugging:: Entering it when a certain function is called. | |
60 * Explicit Debug:: Entering it at a certain point in the program. | |
61 * Using Debugger:: What the debugger does; what you see while in it. | |
62 * Debugger Commands:: Commands used while in the debugger. | |
63 * Invoking the Debugger:: How to call the function @code{debug}. | |
64 * Internals of Debugger:: Subroutines of the debugger, and global variables. | |
65 @end menu | |
66 | |
67 @node Error Debugging | |
68 @subsection Entering the Debugger on an Error | |
69 @cindex error debugging | |
70 @cindex debugging errors | |
71 | |
72 The most important time to enter the debugger is when a Lisp error | |
73 happens. This allows you to investigate the immediate causes of the | |
74 error. | |
75 | |
76 However, entry to the debugger is not a normal consequence of an | |
77 error. Many commands frequently get Lisp errors when invoked in | |
78 inappropriate contexts (such as @kbd{C-f} at the end of the buffer) and | |
79 during ordinary editing it would be very unpleasant to enter the | |
80 debugger each time this happens. If you want errors to enter the | |
81 debugger, set the variable @code{debug-on-error} to non-@code{nil}. | |
82 | |
83 @defopt debug-on-error | |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
84 This variable determines whether the debugger is called when an error is |
6558 | 85 signaled and not handled. If @code{debug-on-error} is @code{t}, all |
86 errors call the debugger. If it is @code{nil}, none call the debugger. | |
87 | |
88 The value can also be a list of error conditions that should call the | |
89 debugger. For example, if you set it to the list | |
90 @code{(void-variable)}, then only errors about a variable that has no | |
91 value invoke the debugger. | |
12067 | 92 |
93 When this variable is non-@code{nil}, Emacs does not catch errors that | |
94 happen in process filter functions and sentinels. Therefore, these | |
95 errors also can invoke the debugger. @xref{Processes}. | |
6558 | 96 @end defopt |
97 | |
15725 | 98 @defopt debug-ignored-errors |
99 This variable specifies certain kinds of errors that should not enter | |
100 the debugger. Its value is a list of error condition symbols and/or | |
101 regular expressions. If the error has any of those condition symbols, | |
102 or if the error message matches any of the regular expressions, then | |
103 that error does not enter the debugger, regardless of the value of | |
104 @code{debug-on-error}. | |
105 | |
106 The normal value of this variable lists several errors that happen often | |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
107 during editing but rarely result from bugs in Lisp programs. However, |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
108 ``rarely'' is not ``never''; if your program fails with an error that |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
109 matches this list, you will need to change this list in order to debug |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
110 the error. The easiest way is usually to set |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
111 @code{debug-ignored-errors} to @code{nil}. |
15725 | 112 @end defopt |
113 | |
21007
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
114 @defopt debug-on-signal |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
115 Normally, errors that are caught by @code{condition-case} never run the |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
116 debugger, even if @code{debug-on-error} is non-@code{nil}. In other |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
117 words, @code{condition-case} gets a chance to handle the error before |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
118 the debugger gets a chance. |
21007
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
119 |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
120 If you set @code{debug-on-signal} non-@code{nil}, then the debugger gets |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
121 first chance at every error; an error will invoke the debugger |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
122 regardless of any @code{condition-case}, if the fits the criterion |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
123 specified by the values of @code{debug-on-error} and |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
124 @code{debug-ignored-errors}. |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
125 |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
126 @strong{Warning:} This variable is strong medicine! Various parts of |
21007
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
127 Emacs handle errors in the normal course of affairs, and you may not |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
128 even realize that errors happen there. If you set |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
129 @code{debug-on-signal} to a non-@code{nil} value, those errors will |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
130 enter the debugger. |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
131 |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
132 @strong{Warning:} @code{debug-on-signal} has no effect when |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
133 @code{debug-on-error} is @code{nil}. |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
134 @end defopt |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
135 |
6558 | 136 To debug an error that happens during loading of the @file{.emacs} |
137 file, use the option @samp{-debug-init}, which binds | |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
138 @code{debug-on-error} to @code{t} while @file{.emacs} is loaded and |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
139 inhibits use of @code{condition-case} to catch init-file errors. |
6558 | 140 |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
141 If your @file{.emacs} file sets @code{debug-on-error}, the effect may |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
142 not last past the end of loading @file{.emacs}. (This is an undesirable |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
143 byproduct of the code that implements the @samp{-debug-init} command |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
144 line option.) The best way to make @file{.emacs} set |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
145 @code{debug-on-error} permanently is with @code{after-init-hook}, like |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
146 this: |
6558 | 147 |
148 @example | |
149 (add-hook 'after-init-hook | |
150 '(lambda () (setq debug-on-error t))) | |
151 @end example | |
152 | |
153 @node Infinite Loops | |
154 @subsection Debugging Infinite Loops | |
155 @cindex infinite loops | |
156 @cindex loops, infinite | |
157 @cindex quitting from infinite loop | |
158 @cindex stopping an infinite loop | |
159 | |
160 When a program loops infinitely and fails to return, your first | |
161 problem is to stop the loop. On most operating systems, you can do this | |
162 with @kbd{C-g}, which causes quit. | |
163 | |
164 Ordinary quitting gives no information about why the program was | |
165 looping. To get more information, you can set the variable | |
166 @code{debug-on-quit} to non-@code{nil}. Quitting with @kbd{C-g} is not | |
167 considered an error, and @code{debug-on-error} has no effect on the | |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
168 handling of @kbd{C-g}. Likewise, @code{debug-on-quit} has no effect on |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
169 errors. |
6558 | 170 |
171 Once you have the debugger running in the middle of the infinite loop, | |
172 you can proceed from the debugger using the stepping commands. If you | |
173 step through the entire loop, you will probably get enough information | |
174 to solve the problem. | |
175 | |
176 @defopt debug-on-quit | |
177 This variable determines whether the debugger is called when @code{quit} | |
178 is signaled and not handled. If @code{debug-on-quit} is non-@code{nil}, | |
179 then the debugger is called whenever you quit (that is, type @kbd{C-g}). | |
180 If @code{debug-on-quit} is @code{nil}, then the debugger is not called | |
181 when you quit. @xref{Quitting}. | |
182 @end defopt | |
183 | |
184 @node Function Debugging | |
185 @subsection Entering the Debugger on a Function Call | |
186 @cindex function call debugging | |
187 @cindex debugging specific functions | |
188 | |
189 To investigate a problem that happens in the middle of a program, one | |
190 useful technique is to enter the debugger whenever a certain function is | |
191 called. You can do this to the function in which the problem occurs, | |
192 and then step through the function, or you can do this to a function | |
193 called shortly before the problem, step quickly over the call to that | |
194 function, and then step through its caller. | |
195 | |
196 @deffn Command debug-on-entry function-name | |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
197 This function requests @var{function-name} to invoke the debugger each time |
6558 | 198 it is called. It works by inserting the form @code{(debug 'debug)} into |
199 the function definition as the first form. | |
200 | |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
201 Any function defined as Lisp code may be set to break on entry, |
6558 | 202 regardless of whether it is interpreted code or compiled code. If the |
203 function is a command, it will enter the debugger when called from Lisp | |
204 and when called interactively (after the reading of the arguments). You | |
205 can't debug primitive functions (i.e., those written in C) this way. | |
206 | |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
207 When @code{debug-on-entry} is called interactively, it prompts for |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
208 @var{function-name} in the minibuffer. If the function is already set |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
209 up to invoke the debugger on entry, @code{debug-on-entry} does nothing. |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
210 @code{debug-on-entry} always returns @var{function-name}. |
6558 | 211 |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
212 @strong{Note:} if you redefine a function after using |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
213 @code{debug-on-entry} on it, the code to enter the debugger is discarded |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
214 by the redefinition. In effect, redefining the function cancels |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
215 the break-on-entry feature for that function. |
6558 | 216 |
217 @example | |
218 @group | |
219 (defun fact (n) | |
220 (if (zerop n) 1 | |
221 (* n (fact (1- n))))) | |
222 @result{} fact | |
223 @end group | |
224 @group | |
225 (debug-on-entry 'fact) | |
226 @result{} fact | |
227 @end group | |
228 @group | |
229 (fact 3) | |
230 @end group | |
231 | |
232 @group | |
233 ------ Buffer: *Backtrace* ------ | |
234 Entering: | |
235 * fact(3) | |
236 eval-region(4870 4878 t) | |
237 byte-code("...") | |
238 eval-last-sexp(nil) | |
239 (let ...) | |
240 eval-insert-last-sexp(nil) | |
241 * call-interactively(eval-insert-last-sexp) | |
242 ------ Buffer: *Backtrace* ------ | |
243 @end group | |
244 | |
245 @group | |
246 (symbol-function 'fact) | |
247 @result{} (lambda (n) | |
248 (debug (quote debug)) | |
249 (if (zerop n) 1 (* n (fact (1- n))))) | |
250 @end group | |
251 @end example | |
252 @end deffn | |
253 | |
254 @deffn Command cancel-debug-on-entry function-name | |
255 This function undoes the effect of @code{debug-on-entry} on | |
256 @var{function-name}. When called interactively, it prompts for | |
12098 | 257 @var{function-name} in the minibuffer. If @var{function-name} is |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
258 @code{nil} or the empty string, it cancels break-on-entry for all |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
259 functions. |
6558 | 260 |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
261 Calling @code{cancel-debug-on-entry} does nothing to a function which is |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
262 not currently set up to break on entry. It always returns |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
263 @var{function-name}. |
6558 | 264 @end deffn |
265 | |
266 @node Explicit Debug | |
267 @subsection Explicit Entry to the Debugger | |
268 | |
269 You can cause the debugger to be called at a certain point in your | |
270 program by writing the expression @code{(debug)} at that point. To do | |
271 this, visit the source file, insert the text @samp{(debug)} at the | |
272 proper place, and type @kbd{C-M-x}. Be sure to undo this insertion | |
273 before you save the file! | |
274 | |
275 The place where you insert @samp{(debug)} must be a place where an | |
276 additional form can be evaluated and its value ignored. (If the value | |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
277 of @code{(debug)} isn't ignored, it will alter the execution of the |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
278 program!) The most common suitable places are inside a @code{progn} or |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
279 an implicit @code{progn} (@pxref{Sequencing}). |
6558 | 280 |
281 @node Using Debugger | |
282 @subsection Using the Debugger | |
283 | |
284 When the debugger is entered, it displays the previously selected | |
285 buffer in one window and a buffer named @samp{*Backtrace*} in another | |
286 window. The backtrace buffer contains one line for each level of Lisp | |
287 function execution currently going on. At the beginning of this buffer | |
288 is a message describing the reason that the debugger was invoked (such | |
289 as the error message and associated data, if it was invoked due to an | |
290 error). | |
291 | |
292 The backtrace buffer is read-only and uses a special major mode, | |
293 Debugger mode, in which letters are defined as debugger commands. The | |
294 usual Emacs editing commands are available; thus, you can switch windows | |
295 to examine the buffer that was being edited at the time of the error, | |
296 switch buffers, visit files, or do any other sort of editing. However, | |
297 the debugger is a recursive editing level (@pxref{Recursive Editing}) | |
298 and it is wise to go back to the backtrace buffer and exit the debugger | |
299 (with the @kbd{q} command) when you are finished with it. Exiting | |
300 the debugger gets out of the recursive edit and kills the backtrace | |
301 buffer. | |
302 | |
303 @cindex current stack frame | |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
304 The backtrace buffer shows you the functions that are executing and |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
305 their argument values. It also allows you to specify a stack frame by |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
306 moving point to the line describing that frame. (A stack frame is the |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
307 place where the Lisp interpreter records information about a particular |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
308 invocation of a function.) The frame whose line point is on is |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
309 considered the @dfn{current frame}. Some of the debugger commands |
6558 | 310 operate on the current frame. |
311 | |
312 The debugger itself must be run byte-compiled, since it makes | |
313 assumptions about how many stack frames are used for the debugger | |
314 itself. These assumptions are false if the debugger is running | |
315 interpreted. | |
316 | |
317 @need 3000 | |
318 | |
319 @node Debugger Commands | |
320 @subsection Debugger Commands | |
321 @cindex debugger command list | |
322 | |
323 Inside the debugger (in Debugger mode), these special commands are | |
324 available in addition to the usual cursor motion commands. (Keep in | |
325 mind that all the usual facilities of Emacs, such as switching windows | |
326 or buffers, are still available.) | |
327 | |
328 The most important use of debugger commands is for stepping through | |
329 code, so that you can see how control flows. The debugger can step | |
330 through the control structures of an interpreted function, but cannot do | |
331 so in a byte-compiled function. If you would like to step through a | |
332 byte-compiled function, replace it with an interpreted definition of the | |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
333 same function. (To do this, visit the source for the function and type |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
334 @kbd{C-M-x} on its definition.) |
6558 | 335 |
336 Here is a list of Debugger mode commands: | |
337 | |
338 @table @kbd | |
339 @item c | |
340 Exit the debugger and continue execution. When continuing is possible, | |
341 it resumes execution of the program as if the debugger had never been | |
342 entered (aside from the effect of any variables or data structures you | |
343 may have changed while inside the debugger). | |
344 | |
345 Continuing is possible after entry to the debugger due to function entry | |
346 or exit, explicit invocation, or quitting. You cannot continue if the | |
347 debugger was entered because of an error. | |
348 | |
349 @item d | |
350 Continue execution, but enter the debugger the next time any Lisp | |
351 function is called. This allows you to step through the | |
352 subexpressions of an expression, seeing what values the subexpressions | |
353 compute, and what else they do. | |
354 | |
355 The stack frame made for the function call which enters the debugger in | |
356 this way will be flagged automatically so that the debugger will be | |
357 called again when the frame is exited. You can use the @kbd{u} command | |
358 to cancel this flag. | |
359 | |
360 @item b | |
361 Flag the current frame so that the debugger will be entered when the | |
362 frame is exited. Frames flagged in this way are marked with stars | |
363 in the backtrace buffer. | |
364 | |
365 @item u | |
366 Don't enter the debugger when the current frame is exited. This | |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
367 cancels a @kbd{b} command on that frame. The visible effect is to |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
368 remove the star from the line in the backtrace buffer. |
6558 | 369 |
370 @item e | |
371 Read a Lisp expression in the minibuffer, evaluate it, and print the | |
12098 | 372 value in the echo area. The debugger alters certain important |
373 variables, and the current buffer, as part of its operation; @kbd{e} | |
374 temporarily restores their outside-the-debugger values so you can | |
375 examine them. This makes the debugger more transparent. By contrast, | |
376 @kbd{M-:} does nothing special in the debugger; it shows you the | |
377 variable values within the debugger. | |
6558 | 378 |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
379 @item R |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
380 Like @kbd{e}, but also save the result of evaluation in the |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
381 buffer @samp{*Debugger-record*}. |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
382 |
6558 | 383 @item q |
384 Terminate the program being debugged; return to top-level Emacs | |
385 command execution. | |
386 | |
387 If the debugger was entered due to a @kbd{C-g} but you really want | |
388 to quit, and not debug, use the @kbd{q} command. | |
389 | |
390 @item r | |
391 Return a value from the debugger. The value is computed by reading an | |
392 expression with the minibuffer and evaluating it. | |
393 | |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
394 The @kbd{r} command is useful when the debugger was invoked due to exit |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
395 from a Lisp call frame (as requested with @kbd{b} or by entering the |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
396 frame with @kbd{d}); then the value specified in the @kbd{r} command is |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
397 used as the value of that frame. It is also useful if you call |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
398 @code{debug} and use its return value. Otherwise, @kbd{r} has the same |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
399 effect as @kbd{c}, and the specified return value does not matter. |
6558 | 400 |
401 You can't use @kbd{r} when the debugger was entered due to an error. | |
402 @end table | |
403 | |
404 @node Invoking the Debugger | |
405 @subsection Invoking the Debugger | |
406 | |
407 Here we describe fully the function used to invoke the debugger. | |
408 | |
409 @defun debug &rest debugger-args | |
410 This function enters the debugger. It switches buffers to a buffer | |
411 named @samp{*Backtrace*} (or @samp{*Backtrace*<2>} if it is the second | |
412 recursive entry to the debugger, etc.), and fills it with information | |
413 about the stack of Lisp function calls. It then enters a recursive | |
414 edit, showing the backtrace buffer in Debugger mode. | |
415 | |
416 The Debugger mode @kbd{c} and @kbd{r} commands exit the recursive edit; | |
417 then @code{debug} switches back to the previous buffer and returns to | |
418 whatever called @code{debug}. This is the only way the function | |
419 @code{debug} can return to its caller. | |
420 | |
421 If the first of the @var{debugger-args} passed to @code{debug} is | |
422 @code{nil} (or if it is not one of the special values in the table | |
12098 | 423 below), then @code{debug} displays the rest of its arguments at the |
6558 | 424 top of the @samp{*Backtrace*} buffer. This mechanism is used to display |
425 a message to the user. | |
426 | |
427 However, if the first argument passed to @code{debug} is one of the | |
428 following special values, then it has special significance. Normally, | |
429 these values are passed to @code{debug} only by the internals of Emacs | |
430 and the debugger, and not by programmers calling @code{debug}. | |
431 | |
432 The special values are: | |
433 | |
434 @table @code | |
435 @item lambda | |
436 @cindex @code{lambda} in debug | |
437 A first argument of @code{lambda} means @code{debug} was called because | |
438 of entry to a function when @code{debug-on-next-call} was | |
439 non-@code{nil}. The debugger displays @samp{Entering:} as a line of | |
440 text at the top of the buffer. | |
441 | |
442 @item debug | |
443 @code{debug} as first argument indicates a call to @code{debug} because | |
444 of entry to a function that was set to debug on entry. The debugger | |
445 displays @samp{Entering:}, just as in the @code{lambda} case. It also | |
446 marks the stack frame for that function so that it will invoke the | |
447 debugger when exited. | |
448 | |
449 @item t | |
450 When the first argument is @code{t}, this indicates a call to | |
451 @code{debug} due to evaluation of a list form when | |
452 @code{debug-on-next-call} is non-@code{nil}. The debugger displays the | |
453 following as the top line in the buffer: | |
454 | |
455 @smallexample | |
456 Beginning evaluation of function call form: | |
457 @end smallexample | |
458 | |
459 @item exit | |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
460 When the first argument is @code{exit}, it indicates the exit of a stack |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
461 frame previously marked to invoke the debugger on exit. The second |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
462 argument given to @code{debug} in this case is the value being returned |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
463 from the frame. The debugger displays @samp{Return value:} in the top |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
464 line of the buffer, followed by the value being returned. |
6558 | 465 |
466 @item error | |
467 @cindex @code{error} in debug | |
468 When the first argument is @code{error}, the debugger indicates that | |
469 it is being entered because an error or @code{quit} was signaled and not | |
470 handled, by displaying @samp{Signaling:} followed by the error signaled | |
471 and any arguments to @code{signal}. For example, | |
472 | |
473 @example | |
474 @group | |
475 (let ((debug-on-error t)) | |
476 (/ 1 0)) | |
477 @end group | |
478 | |
479 @group | |
480 ------ Buffer: *Backtrace* ------ | |
481 Signaling: (arith-error) | |
482 /(1 0) | |
483 ... | |
484 ------ Buffer: *Backtrace* ------ | |
485 @end group | |
486 @end example | |
487 | |
488 If an error was signaled, presumably the variable | |
489 @code{debug-on-error} is non-@code{nil}. If @code{quit} was signaled, | |
490 then presumably the variable @code{debug-on-quit} is non-@code{nil}. | |
491 | |
492 @item nil | |
493 Use @code{nil} as the first of the @var{debugger-args} when you want | |
494 to enter the debugger explicitly. The rest of the @var{debugger-args} | |
495 are printed on the top line of the buffer. You can use this feature to | |
496 display messages---for example, to remind yourself of the conditions | |
497 under which @code{debug} is called. | |
498 @end table | |
499 @end defun | |
500 | |
501 @node Internals of Debugger | |
502 @subsection Internals of the Debugger | |
503 | |
504 This section describes functions and variables used internally by the | |
505 debugger. | |
506 | |
507 @defvar debugger | |
508 The value of this variable is the function to call to invoke the | |
509 debugger. Its value must be a function of any number of arguments (or, | |
510 more typically, the name of a function). Presumably this function will | |
511 enter some kind of debugger. The default value of the variable is | |
512 @code{debug}. | |
513 | |
514 The first argument that Lisp hands to the function indicates why it | |
515 was called. The convention for arguments is detailed in the description | |
516 of @code{debug}. | |
517 @end defvar | |
518 | |
519 @deffn Command backtrace | |
520 @cindex run time stack | |
521 @cindex call stack | |
522 This function prints a trace of Lisp function calls currently active. | |
523 This is the function used by @code{debug} to fill up the | |
524 @samp{*Backtrace*} buffer. It is written in C, since it must have access | |
525 to the stack to determine which function calls are active. The return | |
526 value is always @code{nil}. | |
527 | |
528 In the following example, a Lisp expression calls @code{backtrace} | |
529 explicitly. This prints the backtrace to the stream | |
530 @code{standard-output}: in this case, to the buffer | |
531 @samp{backtrace-output}. Each line of the backtrace represents one | |
532 function call. The line shows the values of the function's arguments if | |
533 they are all known. If they are still being computed, the line says so. | |
534 The arguments of special forms are elided. | |
535 | |
536 @smallexample | |
537 @group | |
538 (with-output-to-temp-buffer "backtrace-output" | |
539 (let ((var 1)) | |
540 (save-excursion | |
541 (setq var (eval '(progn | |
542 (1+ var) | |
543 (list 'testing (backtrace)))))))) | |
544 | |
545 @result{} nil | |
546 @end group | |
547 | |
548 @group | |
549 ----------- Buffer: backtrace-output ------------ | |
550 backtrace() | |
551 (list ...computing arguments...) | |
552 (progn ...) | |
553 eval((progn (1+ var) (list (quote testing) (backtrace)))) | |
554 (setq ...) | |
555 (save-excursion ...) | |
556 (let ...) | |
557 (with-output-to-temp-buffer ...) | |
558 eval-region(1973 2142 #<buffer *scratch*>) | |
559 byte-code("... for eval-print-last-sexp ...") | |
560 eval-print-last-sexp(nil) | |
561 * call-interactively(eval-print-last-sexp) | |
562 ----------- Buffer: backtrace-output ------------ | |
563 @end group | |
564 @end smallexample | |
565 | |
566 The character @samp{*} indicates a frame whose debug-on-exit flag is | |
567 set. | |
568 @end deffn | |
569 | |
570 @ignore @c Not worth mentioning | |
571 @defopt stack-trace-on-error | |
572 @cindex stack trace | |
573 This variable controls whether Lisp automatically displays a | |
574 backtrace buffer after every error that is not handled. A quit signal | |
575 counts as an error for this variable. If it is non-@code{nil} then a | |
576 backtrace is shown in a pop-up buffer named @samp{*Backtrace*} on every | |
577 error. If it is @code{nil}, then a backtrace is not shown. | |
578 | |
579 When a backtrace is shown, that buffer is not selected. If either | |
580 @code{debug-on-quit} or @code{debug-on-error} is also non-@code{nil}, then | |
581 a backtrace is shown in one buffer, and the debugger is popped up in | |
582 another buffer with its own backtrace. | |
583 | |
584 We consider this feature to be obsolete and superseded by the debugger | |
585 itself. | |
586 @end defopt | |
587 @end ignore | |
588 | |
589 @defvar debug-on-next-call | |
590 @cindex @code{eval}, and debugging | |
591 @cindex @code{apply}, and debugging | |
592 @cindex @code{funcall}, and debugging | |
593 If this variable is non-@code{nil}, it says to call the debugger before | |
594 the next @code{eval}, @code{apply} or @code{funcall}. Entering the | |
595 debugger sets @code{debug-on-next-call} to @code{nil}. | |
596 | |
597 The @kbd{d} command in the debugger works by setting this variable. | |
598 @end defvar | |
599 | |
600 @defun backtrace-debug level flag | |
601 This function sets the debug-on-exit flag of the stack frame @var{level} | |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
602 levels down the stack, giving it the value @var{flag}. If @var{flag} is |
6558 | 603 non-@code{nil}, this will cause the debugger to be entered when that |
604 frame later exits. Even a nonlocal exit through that frame will enter | |
605 the debugger. | |
606 | |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
607 This function is used only by the debugger. |
6558 | 608 @end defun |
609 | |
610 @defvar command-debug-status | |
12098 | 611 This variable records the debugging status of the current interactive |
6558 | 612 command. Each time a command is called interactively, this variable is |
613 bound to @code{nil}. The debugger can set this variable to leave | |
21007
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
614 information for future debugger invocations during the same command |
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
615 invocation. |
6558 | 616 |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
617 The advantage, for the debugger, of using this variable rather than an |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
618 ordinary global variable is that the data will never carry over to a |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
619 subsequent command invocation. |
6558 | 620 @end defvar |
621 | |
622 @defun backtrace-frame frame-number | |
623 The function @code{backtrace-frame} is intended for use in Lisp | |
624 debuggers. It returns information about what computation is happening | |
625 in the stack frame @var{frame-number} levels down. | |
626 | |
627 If that frame has not evaluated the arguments yet (or is a special | |
628 form), the value is @code{(nil @var{function} @var{arg-forms}@dots{})}. | |
629 | |
630 If that frame has evaluated its arguments and called its function | |
631 already, the value is @code{(t @var{function} | |
632 @var{arg-values}@dots{})}. | |
633 | |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
634 In the return value, @var{function} is whatever was supplied as the |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
635 @sc{car} of the evaluated list, or a @code{lambda} expression in the |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
636 case of a macro call. If the function has a @code{&rest} argument, that |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
637 is represented as the tail of the list @var{arg-values}. |
6558 | 638 |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
639 If @var{frame-number} is out of range, @code{backtrace-frame} returns |
6558 | 640 @code{nil}. |
641 @end defun | |
642 | |
643 @node Syntax Errors | |
644 @section Debugging Invalid Lisp Syntax | |
645 | |
646 The Lisp reader reports invalid syntax, but cannot say where the real | |
647 problem is. For example, the error ``End of file during parsing'' in | |
648 evaluating an expression indicates an excess of open parentheses (or | |
649 square brackets). The reader detects this imbalance at the end of the | |
650 file, but it cannot figure out where the close parenthesis should have | |
651 been. Likewise, ``Invalid read syntax: ")"'' indicates an excess close | |
652 parenthesis or missing open parenthesis, but does not say where the | |
653 missing parenthesis belongs. How, then, to find what to change? | |
654 | |
655 If the problem is not simply an imbalance of parentheses, a useful | |
656 technique is to try @kbd{C-M-e} at the beginning of each defun, and see | |
657 if it goes to the place where that defun appears to end. If it does | |
658 not, there is a problem in that defun. | |
659 | |
660 However, unmatched parentheses are the most common syntax errors in | |
661 Lisp, and we can give further advice for those cases. | |
662 | |
663 @menu | |
664 * Excess Open:: How to find a spurious open paren or missing close. | |
665 * Excess Close:: How to find a spurious close paren or missing open. | |
666 @end menu | |
667 | |
668 @node Excess Open | |
669 @subsection Excess Open Parentheses | |
670 | |
671 The first step is to find the defun that is unbalanced. If there is | |
672 an excess open parenthesis, the way to do this is to insert a | |
673 close parenthesis at the end of the file and type @kbd{C-M-b} | |
674 (@code{backward-sexp}). This will move you to the beginning of the | |
675 defun that is unbalanced. (Then type @kbd{C-@key{SPC} C-_ C-u | |
676 C-@key{SPC}} to set the mark there, undo the insertion of the | |
677 close parenthesis, and finally return to the mark.) | |
678 | |
679 The next step is to determine precisely what is wrong. There is no | |
21007
66d807bdc5b4
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
15725
diff
changeset
|
680 way to be sure of this except by studying the program, but often the |
6558 | 681 existing indentation is a clue to where the parentheses should have |
682 been. The easiest way to use this clue is to reindent with @kbd{C-M-q} | |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
683 and see what moves. @strong{But don't do this yet!} Keep reading, |
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
684 first. |
6558 | 685 |
686 Before you do this, make sure the defun has enough close parentheses. | |
687 Otherwise, @kbd{C-M-q} will get an error, or will reindent all the rest | |
688 of the file until the end. So move to the end of the defun and insert a | |
689 close parenthesis there. Don't use @kbd{C-M-e} to move there, since | |
690 that too will fail to work until the defun is balanced. | |
691 | |
692 Now you can go to the beginning of the defun and type @kbd{C-M-q}. | |
693 Usually all the lines from a certain point to the end of the function | |
694 will shift to the right. There is probably a missing close parenthesis, | |
695 or a superfluous open parenthesis, near that point. (However, don't | |
696 assume this is true; study the code to make sure.) Once you have found | |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
697 the discrepancy, undo the @kbd{C-M-q} with @kbd{C-_}, since the old |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
698 indentation is probably appropriate to the intended parentheses. |
6558 | 699 |
700 After you think you have fixed the problem, use @kbd{C-M-q} again. If | |
701 the old indentation actually fit the intended nesting of parentheses, | |
702 and you have put back those parentheses, @kbd{C-M-q} should not change | |
703 anything. | |
704 | |
705 @node Excess Close | |
706 @subsection Excess Close Parentheses | |
707 | |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
708 To deal with an excess close parenthesis, first insert an open |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
709 parenthesis at the beginning of the file, back up over it, and type |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
710 @kbd{C-M-f} to find the end of the unbalanced defun. (Then type |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
711 @kbd{C-@key{SPC} C-_ C-u C-@key{SPC}} to set the mark there, undo the |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
712 insertion of the open parenthesis, and finally return to the mark.) |
6558 | 713 |
714 Then find the actual matching close parenthesis by typing @kbd{C-M-f} | |
21682
90da2489c498
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
21007
diff
changeset
|
715 at the beginning of that defun. This will leave you somewhere short of |
6558 | 716 the place where the defun ought to end. It is possible that you will |
717 find a spurious close parenthesis in that vicinity. | |
718 | |
719 If you don't see a problem at that point, the next thing to do is to | |
720 type @kbd{C-M-q} at the beginning of the defun. A range of lines will | |
721 probably shift left; if so, the missing open parenthesis or spurious | |
722 close parenthesis is probably near the first of those lines. (However, | |
723 don't assume this is true; study the code to make sure.) Once you have | |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
724 found the discrepancy, undo the @kbd{C-M-q} with @kbd{C-_}, since the |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
725 old indentation is probably appropriate to the intended parentheses. |
6558 | 726 |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
727 After you think you have fixed the problem, use @kbd{C-M-q} again. If |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
728 the old indentation actually fit the intended nesting of parentheses, |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
729 and you have put back those parentheses, @kbd{C-M-q} should not change |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
730 anything. |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
731 |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
732 @node Compilation Errors, Edebug, Syntax Errors, Debugging |
6558 | 733 @section Debugging Problems in Compilation |
734 | |
735 When an error happens during byte compilation, it is normally due to | |
736 invalid syntax in the program you are compiling. The compiler prints a | |
737 suitable error message in the @samp{*Compile-Log*} buffer, and then | |
738 stops. The message may state a function name in which the error was | |
739 found, or it may not. Either way, here is how to find out where in the | |
740 file the error occurred. | |
741 | |
742 What you should do is switch to the buffer @w{@samp{ *Compiler Input*}}. | |
743 (Note that the buffer name starts with a space, so it does not show | |
744 up in @kbd{M-x list-buffers}.) This buffer contains the program being | |
745 compiled, and point shows how far the byte compiler was able to read. | |
746 | |
747 If the error was due to invalid Lisp syntax, point shows exactly where | |
748 the invalid syntax was @emph{detected}. The cause of the error is not | |
749 necessarily near by! Use the techniques in the previous section to find | |
750 the error. | |
751 | |
752 If the error was detected while compiling a form that had been read | |
753 successfully, then point is located at the end of the form. In this | |
7214
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
754 case, this technique can't localize the error precisely, but can still |
5a6f2a00002d
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
6558
diff
changeset
|
755 show you which function to check. |
6558 | 756 |
757 @include edebug.texi |