changeset 58279:76be0b364843

(Function Debugging, Explicit Debug): Clarified. (Test Coverage): Don't talk about "splotches". Clarified.
author Richard M. Stallman <rms@gnu.org>
date Tue, 16 Nov 2004 17:26:18 +0000
parents 31a2a9c6a64d
children 08330213d737
files lispref/debugging.texi
diffstat 1 files changed, 18 insertions(+), 15 deletions(-) [+]
line wrap: on
line diff
--- a/lispref/debugging.texi	Tue Nov 16 17:20:32 2004 +0000
+++ b/lispref/debugging.texi	Tue Nov 16 17:26:18 2004 +0000
@@ -221,6 +221,8 @@
 discarded by the redefinition.  In effect, redefining the function
 cancels the break-on-entry feature for that function.
 
+Here's an example to illustrate use of this function:
+
 @example
 @group
 (defun fact (n)
@@ -276,9 +278,9 @@
   You can cause the debugger to be called at a certain point in your
 program by writing the expression @code{(debug)} at that point.  To do
 this, visit the source file, insert the text @samp{(debug)} at the
-proper place, and type @kbd{C-M-x}.  @strong{Warning:} if you do this
-for temporary debugging purposes, be sure to undo this insertion before
-you save the file!
+proper place, and type @kbd{C-M-x} (@code{eval-defun}, a Lisp mode key
+binding).  @strong{Warning:} if you do this for temporary debugging
+purposes, be sure to undo this insertion before you save the file!
 
   The place where you insert @samp{(debug)} must be a place where an
 additional form can be evaluated and its value ignored.  (If the value
@@ -746,20 +748,21 @@
 @findex testcover-start
 @findex testcover-mark-all
 @findex testcover-next-mark
-  You can do coverage testing for a file of Lisp code by first using
-the command @kbd{M-x testcover-start @key{RET} @var{file} @key{RET}}
-to instrument it.  Then test your code by calling it one or more
-times.  Then use the command @kbd{M-x testcover-mark-all} to display
-``splotches'' on the code to show where coverage is insufficient.  The
-command @kbd{M-x testcover-next-mark} will move point forward to the
-next spot that has a splotch.
+  You can do coverage testing for a file of Lisp code by loading the
+@code{testcover} library and using the command @kbd{M-x
+testcover-start @key{RET} @var{file} @key{RET}} to instrument the
+code.  Then test your code by calling it one or more times.  Then use
+the command @kbd{M-x testcover-mark-all} to display colored highlights
+on the code to show where coverage is insufficient.  The command
+@kbd{M-x testcover-next-mark} will move point forward to the next
+highlighted spot.
 
-  Normally, a red splotch indicates the form was never completely
-evaluated; a brown splotch means it always evaluated to the same value
-(meaning there has been little testing of what is done with the
-result).  However, the red splotch is skipped for forms that can't
+  Normally, a red highlight indicates the form was never completely
+evaluated; a brown highlight means it always evaluated to the same
+value (meaning there has been little testing of what is done with the
+result).  However, the red highlight is skipped for forms that can't
 possibly complete their evaluation, such as @code{error}.  The brown
-splotch is skipped for forms that are expected to always evaluate to
+highlight is skipped for forms that are expected to always evaluate to
 the same value, such as @code{(setq x 14)}.
 
   For difficult cases, you can add do-nothing macros to your code to