; Fix last change

* src/eval.c (Fdebugger_trap): Minor wording changes in doc
string.

* etc/DEBUG: Some copyedits of a recently-added text.

1 files changed, 12 insertions, 9 deletions

diff --git a/etc/DEBUG b/etc/DEBUG
index 44f19900c64..dc1601a34f8 100644
--- a/etc/DEBUG
+++ b/etc/DEBUG
@@ -211,16 +211,19 @@ the debugger, but before running it, is the most efficient way of
 making sure control will be returned to the debugger when you need
 that.
 
-There is a default function to give control to the debugger.  It is
-called debugger-trap.  This is a do-nothing primitive, as a convenient
-point to return control to the debugger.  You can invoke interactively
-with "M-x debugger-trap RET".  The src/.gdbinit file in the Emacs source
-distribution sets a breakpoint on this function.
-
-'Fsignal' is a very useful place to put a breakpoint in.  All Lisp
+The function 'debugger-trap' is a do-nothing interactive command that
+exists to give control to the debugger.  It is convenient to set a
+breakpoint there to give control to the debugger when the function is
+called.  You can invoke it interactively with "M-x debugger-trap RET".
+The src/.gdbinit file in the Emacs source distribution sets a breakpoint
+in this function, so if you arrange for .gdbinit to be loaded, or load
+it manually in a debugging session, the breakpoint is set for you
+automatically.
+
+'Fsignal' is another very useful place to put a breakpoint in.  All Lisp
 errors go through there.  If you are only interested in errors that
-would fire the Lisp debugger, breaking at 'maybe_call_debugger' is
-useful.
+would fire the Lisp debugger, breaking at 'maybe_call_debugger' is a
+useful alternative.
 
 It is also useful to have a guaranteed way to return to the debugger
 at any arbitrary time.  When using X, this is easy: type C-z at the