Merge branch 'dgud/debugger/doc' into maint

* dgud/debugger/doc:
  debugger: Editorial changes in documentation

8 files changed, 743 insertions, 696 deletions

diff --git a/lib/debugger/doc/src/book.xml b/lib/debugger/doc/src/book.xml
index 071a04eb61..5424ef2c04 100644
--- a/lib/debugger/doc/src/book.xml
+++ b/lib/debugger/doc/src/book.xml
@@ -47,4 +47,3 @@
   <index/>
 </book>
 
-
diff --git a/lib/debugger/doc/src/debugger.xml b/lib/debugger/doc/src/debugger.xml
index 15d498d5ae..1ecdbcd064 100644
--- a/lib/debugger/doc/src/debugger.xml
+++ b/lib/debugger/doc/src/debugger.xml
@@ -4,7 +4,7 @@
 <erlref>
   <header>
     <copyright>
-      <year>2002</year><year>2013</year>
+      <year>2002</year><year>2016</year>
       <holder>Ericsson AB. All Rights Reserved.</holder>
     </copyright>
     <legalnotice>
@@ -29,7 +29,7 @@
     <rev></rev>
   </header>
   <module>debugger</module>
-  <modulesummary>Erlang Debugger</modulesummary>
+  <modulesummary>Erlang Debugger.</modulesummary>
   <description>
     <p>Erlang Debugger for debugging and testing of Erlang programs.</p>
   </description>
@@ -48,14 +48,14 @@
       <desc>
 	<p>Starts Debugger.</p>
 	
-	<p>If given a file name as argument, Debugger will try to load
-	  its settings from this file. Refer to Debugger User's Guide
-	  for more information about settings.</p>
+	<p>If a filename is specified as argument, Debugger tries to load
+	  its settings from this file. For details about settings, see
+	  the User's Guide.</p>
 
-	<p>If given <c>local</c> as argument, Debugger will interpret
-	  code only at the current node. If given <c>global</c> as
-	  argument, Debugger will interpret code at all known nodes,
-	  this is the default.</p>
+	<p>If <c>local</c> is specified as argument, Debugger interprets
+	  code only at the current node. If <c>global</c> is specified as
+	  argument, Debugger interprets code at all known nodes, this
+	  is the default.</p>
       </desc>
     </func>
 
@@ -67,11 +67,9 @@
 	<v>Args = [term()]</v>
       </type>
       <desc>
-	<p>This function can be used to debug a single process.
-	  The module <c>Module</c> is interpreted and
-	  <c>apply(Module,Name,Args)</c> is called. This will open an
-	  Attach Process window, refer to Debugger User's Guide for
-	  more information.</p>
+	<p>Debugs a single process. The module <c>Module</c> is interpreted
+	  and <c>apply(Module,Name,Args)</c> is called. This opens an
+	  Attach Process window. For details, see the User's Guide.</p>
       </desc>
     </func>
   </funcs>
diff --git a/lib/debugger/doc/src/debugger_chapter.xml b/lib/debugger/doc/src/debugger_chapter.xml
index 98fe4ae377..45dfdb3776 100644
--- a/lib/debugger/doc/src/debugger_chapter.xml
+++ b/lib/debugger/doc/src/debugger_chapter.xml
@@ -4,7 +4,7 @@
 <chapter>
 <header>
     <copyright>
-      <year>1997</year><year>2013</year>
+      <year>1997</year><year>2016</year>
       <holder>Ericsson AB. All Rights Reserved.</holder>
     </copyright>
     <legalnotice>
@@ -31,97 +31,92 @@
   </header>
 
   <section>
-    <title>Introduction</title>
+    <title>Getting Started</title>
 
-    <p><em>Debugger</em> is a graphical user interface for the Erlang
-      interpreter, which can be used for debugging and testing of
-      Erlang programs. For example, breakpoints can be set, code can be
-      single stepped and variable values can be displayed and changed.
-    </p>
+    <p>To use Debugger, the basic steps are as follows:</p>
 
-    <p>The Erlang interpreter can also be accessed via the interface
-      module <c>int</c>, see <seealso marker="int">int(3)</seealso>.
-    </p>
+    <p><em>Step 1.</em> Start Debugger by calling
+      <c>debugger:start()</c>.</p>
 
-    <p><em>Warning:</em> Note that the Debugger at some point might
-      start tracing on the processes which execute the interpreted
-      code. This means that a conflict will occur if tracing by other
-      means is started on any of these processes.</p>
-  </section>  
+    <p>The <seealso marker="#monitor">Monitor window</seealso> is
+      displayed with information about all debugged processes,
+      interpreted modules, and selected options. Initially there are
+      normally no debugged processes. First, it must be specified which
+      modules that are to be <em>debugged</em> (also called
+      <em>interpreted</em>). Proceed as follows:</p>
 
-  <section>
-    <title>Getting Started with Debugger</title>
+    <p><em>Step 2.</em> Select <em>Module > Interpret...</em> in the
+      Monitor window.</p>
 
-    <p>Start Debugger by calling <c>debugger:start()</c>. It will start
-      the <seealso marker="#monitor">Monitor window</seealso> showing
-      information about all debugged processes, interpreted modules and
-      selected options.</p>
+    <p>The <seealso marker="#interpret">Interpret Modules window</seealso>
+      is displayed.</p>
 
-    <p>Initially there are normally no debugged processes. First, it
-      must be specified which modules should be <em>debugged</em>, or
-      <em>interpreted</em> as it is also called. This is done by
-      choosing <em>Module->Interpret...</em> in the Monitor window and
-      then selecting the appropriate modules from the
-      <seealso marker="#interpret">Interpret Dialog window</seealso>.
-    </p>
+    <p><em>Step 3.</em> Select the appropriate modules from the Interpret
+      Dialog window.</p>
 
     <note>
-      <p>Only modules compiled with the option <c>debug_info</c> set
-	can be interpreted. Non-interpretable modules are shown within
-	parenthesis in the Interpret Dialog window.</p>
+      <p>Only modules compiled with option <c>debug_info</c> set can be
+        interpreted. Non-interpretable modules are displayed within
+        parenthesis in the Interpret Modules window.</p>
     </note>
 
-    <p>When a module is interpreted, it can be viewed in a
-      <seealso marker="#view">View Module window</seealso>. This is done
-      by selecting the module from the <em>Module->module->View</em>
-      menu. The contents of the source file is shown and it is possible
-      to set <seealso marker="#breakpoints">breakpoints</seealso>.</p>
-
-    <p>Now the program that should be debugged can be started. This is
-      done the normal way from the Erlang shell. All processes executing
-      code in interpreted modules will be displayed in the Monitor
-      window. It is possible to <em>attach</em> to one of these
-      processes, by double-clicking it, or by selecting the process and
-      then choosing <em>Process->Attach</em>.</p>
-
-    <p>Attaching to a process will result in a
-      <seealso marker="#attach">Attach Process window</seealso> being
-      opened for this process. From the Attach Process window, it is
-      possible to control the process execution, inspect variable
-      values, set breakpoints etc.</p>
+    <p><em>Step 4.</em> In the Monitor window, select
+      <em>Module > the module to be interpreted > View</em>.</p>
+
+    <p>The contents of the source file is displayed in the
+      <seealso marker="#view">View Module window</seealso>.</p>
+
+    <p><em>Step 5.</em> Set the
+      <seealso marker="#breakpoints">breakpoints</seealso>, if any.</p>
+
+    <p><em>Step 6.</em> Start the program to be debugged. This is done
+      the normal way from the Erlang shell.</p>
+
+    <p>All processes executing code in interpreted modules are displayed
+      in the Monitor window.</p>
+
+    <p><em>Step 7.</em> To <em>attach</em> to one of these processes,
+      double-click it, or select the process and then choose
+      <em>Process > Attach</em>. Attaching to a process opens an
+      <seealso marker="#attach">Attach Process window</seealso> for this
+      process.</p>
+
+    <p><em>Step 8.</em> From the Attach Process window, you can control
+      the process execution, inspect variable values, set breakpoints,
+      and so on.</p>
   </section>
 
   <section>
     <marker id="breakpoints"/>
-    <title>Breakpoints and Break Dialogue Windows</title>
+    <title>Breakpoints and Break Dialog Windows</title>
     
     <p>Once the appropriate modules are interpreted, breakpoints can
       be set at relevant locations in the source code. Breakpoints are
       specified on a line basis. When a process reaches a breakpoint,
-      it stops and waits for commands (step, skip, continue,...) from
-      the user.</p>
+      it stops and waits for commands (<em>Step</em>, <em>Skip</em>,
+      <em>Continue</em> ...) from the user.</p>
 
     <note>
       <p>When a process reaches a breakpoint, only that process is
-	stopped. Other processes are not affected.</p>
+        stopped. Other processes are not affected.</p>
     </note>
 
-    <p>Breakpoints are created and deleted using the Break menu of
-      the Monitor window, View Module window and Attach Process window.
-    </p>
+    <p>Breakpoints are created and deleted using the <em>Break</em> menu of
+      either the Monitor window, View Module window, or Attach Process
+      window.</p>
 
     <section>
       <title>Executable Lines</title>
 
-      <p>To have effect, a breakpoint must be set at an
-	<em>executable line</em>, which is a line of code containing an
-	executable expression such as a matching or a function call.
-	A blank line or a line containing a comment, function head or
-	pattern in a <c>case</c>- or <c>receive</c> statement is not
-	executable.</p>
+      <p>To have an effect, a breakpoint must be set at an
+        <em>executable line</em>, which is a line of code containing an
+        executable expression such as a matching or a function call.
+        A blank line or a line containing a comment, function head, or
+        pattern in a <c>case</c> statement or <c>receive</c> statement is not
+        executable.</p>
 
-      <p>In the example below, lines number 2, 4, 6, 8 and 11 are
-	executable lines:</p>
+      <p>In the following example, lines 2, 4, 6, 8, and 11 are
+        executable lines:</p>
       <pre>
 1: is_loaded(Module,Compiled) ->
 2:   case get_file(Module,Compiled) of
@@ -141,17 +136,15 @@
       <title>Status and Trigger Action</title>
 
       <p>A breakpoint can be either <em>active</em> or
-	<em>inactive</em>. Inactive breakpoints are ignored.</p>
-
-      <p>Each breakpoint has a <em>trigger action</em> which specifies
-	what should happen when a process has reached it (and stopped):
-      </p>
-      <list>
-	<item><em>enable</em> Breakpoint should remain active (default).
-	</item>
-	<item><em>disable</em> Breakpoint should be made inactive.
-	</item>
-	<item><em>delete</em> Breakpoint should be deleted.</item>
+        <em>inactive</em>. Inactive breakpoints are ignored.</p>
+
+      <p>Each breakpoint has a <em>trigger action</em> that specifies
+        what is to happen when a process has reached it (and stopped):</p>
+      <list type="bulleted">
+        <item><em>Enable</em> - Breakpoint is to remain active (default).
+        </item>
+        <item><em>Disable</em> - Breakpoint is to be made inactive.</item>
+        <item><em>Delete</em> - Breakpoint is to be deleted.</item>
       </list>
     </section>
 
@@ -161,54 +154,56 @@
       <p>A line breakpoint is created at a certain line in a module.</p>
 
       <image file="images/line_break_dialog.jpg">
-	<icaption>The Line Break Dialog Window.</icaption>
+        <icaption>Line Break Dialog Window</icaption>
       </image>
 
-      <p>Right-clicking the Module entry will open a popup menu from
-	which the appropriate module can be selected.</p>
+     <p>Right-click the <em>Module</em> entry to open a popup menu from
+       which the appropriate module can be selected.</p>
 
-      <p>A line breakpoint can also be created (and deleted) by
-	double-clicking the line when the module is displayed in
-	the View Module or Attach Process window.</p>
+     <p>A line breakpoint can also be created (and deleted) by
+       double-clicking the line when the module is displayed in
+       the View Module window or Attach Process window.</p>
     </section>
 
     <section>
       <title>Conditional Breakpoints</title>
 
       <p>A conditional breakpoint is created at a certain line in
-	the module, but a process reaching the breakpoint will stop
-	only if a given condition is true.</p>
+        the module, but a process reaching the breakpoint stops
+        only if a specified condition is true.</p>
 
       <p>The condition is specified by the user as a module name
-	<c>CModule</c> and a function name <c>CFunction</c>. When a
-	process reaches the breakpoint,
-	<c>CModule:CFunction(Bindings)</c> will be evaluated. If and
-	only if this function call returns <c>true</c>, the process
-	will stop. If the function call returns <c>false</c>,
-	the breakpoint will be silently ignored.</p>
-
-      <p><c>Bindings</c> is a list of variable bindings. Use
-	the function <c>int:get_binding(Variable,Bindings)</c> to
-	retrieve the value of <c>Variable</c> (given as an atom).
-	The function returns <c>unbound</c> or <c>{value,Value}</c>.</p>
+        <c>CModule</c> and a function name <c>CFunction</c>. When a
+        process reaches the breakpoint,
+        <c>CModule:CFunction(Bindings)</c> is evaluated. If and
+        only if this function call returns <c>true</c>, the process
+        stops. If the function call returns <c>false</c>,
+        the breakpoint is silently ignored.</p>
+
+      <p><c>Bindings</c> is a list of variable bindings. To retrieve the
+        value of <c>Variable</c> (given as an atom), use function
+        <seealso marker="int#get_binding/2"><c>int:get_binding(Variable,Bindings)</c></seealso>.
+        The function returns <c>unbound</c> or <c>{value,Value}</c>.</p>
 	
       <image file="images/cond_break_dialog.jpg">
-	<icaption>The Conditional Break Dialog Window.</icaption>
+        <icaption>Conditional Break Dialog Window</icaption>
       </image>
 
-      <p>Right-clicking the Module entry will open a popup menu from
-	which the appropriate module can be selected.</p>
+      <p>Right-click the <em>Module</em> entry to open a popup menu from
+        which the appropriate module can be selected.</p>
 
-      <p>Example: A conditional breakpoint calling
-	<c>c_test:c_break/1</c> is added at line 6 in the module
+      <p><em>Example:</em></p>
+
+      <p>A conditional breakpoint calling
+        <c>c_test:c_break/1</c> is added at line 6 in module
 	<c>fact</c>. Each time the breakpoint is reached, the function is
-	called, and when <c>N</c> is equal to 3 it returns <c>true</c>,
-	and the process stops.</p>
-	
+	called. When <c>N</c> is equal to 3, the function returns
+        <c>true</c> and the process stops.</p>
+
       <p>Extract from <c>fact.erl</c>:</p>
       <pre>
-5.   fac(0) -> 1;
-6.   fac(N) when N > 0, is_integer(N) -> N * fac(N-1).</pre>
+5. fac(0) -> 1;
+6. fac(N) when N > 0, is_integer(N) -> N * fac(N-1).</pre>
 
       <p>Definition of <c>c_test:c_break/1</c>:</p>
       <pre>
@@ -228,18 +223,18 @@ c_break(Bindings) ->
       <title>Function Breakpoints</title>
 
       <p>A function breakpoint is a set of line breakpoints, one at
-	the first line of each clause in the given function.</p>
+        the first line of each clause in the specified function.</p>
 
       <image file="images/function_break_dialog.jpg">
-	<icaption>The Function Break Dialog Window.</icaption>
+        <icaption>Function Break Dialog Window</icaption>
       </image>
 
-      <p>Right-clicking the Module entry will open a popup menu from
-	which the appropriate module can be selected.</p>
+      <p>To open a popup menu from which the appropriate module can be
+        selected, right-click the <em>Module</em> entry.</p>
 
-      <p>Clicking the Ok button (or 'Return' or 'Tab') when a module
-	name has been given, will bring up all functions of the module
-	in the listbox.</p>
+      <p>To bring up all functions of the module in the listbox,
+        click the <em>OK</em> button (or press the <em>Return</em>
+        or <em>Tab</em> key) when a module name has been specified,.</p>
     </section>
   </section>
 
@@ -249,7 +244,7 @@ c_break(Bindings) ->
 
     <p>The Erlang emulator keeps track of a <em>stack trace</em>,
       information about recent function calls. This information is
-      used, for example, if an error occurs:</p>
+      used if an error occurs, for example:</p>
     <pre>
 1> <input>catch a+1.</input>
 {'EXIT',{badarith,[{erlang,'+',[a,1],[]},
@@ -259,602 +254,597 @@ c_break(Bindings) ->
                    {shell,eval_exprs,7,[{file,"shell.erl"},{line,629}]},
                    {shell,eval_loop,3,[{file,"shell.erl"},{line,614}]}]}}</pre>
 
-    <p>See the Erlang Reference Manual,
-      <seealso marker="doc/reference_manual:errors">
-      Errors and Error Handling</seealso>,
-      for more information about the stack trace.</p>
+    <p>For details about the stack trace, see section
+      <seealso marker="doc/reference_manual:errors">Errors and Error Handling</seealso>
+      in the Erlang Reference Manual.</p>
 
-    <p>The Debugger emulates the stack trace by keeping track of recently
+    <p>Debugger emulates the stack trace by keeping track of recently
       called interpreted functions. (The real stack trace cannot be
-      used, as it shows which functions of the Debugger have been
-      called, rather than which interpreted functions).</p>
+      used, as it shows which functions of Debugger have been
+      called, rather than which interpreted functions.)</p>
 
     <p>This information can be used to traverse the chain of function
-      calls, using the 'Up' and 'Down' buttons of
-      <seealso marker="#attach">the Attach Process window</seealso>.
-    </p>
+      calls, using the <em>Up</em> and <em>Down</em> buttons in the
+      <seealso marker="#attach">Attach Process window</seealso>.</p>
 
-    <p>By default, the Debugger only saves information about recursive
+    <p>By default, Debugger only saves information about recursive
       function calls, that is, function calls that have not yet returned
-      a value (option 'Stack On, No Tail').</p>
+      a value (option <em>Stack On, No Tail</em>).</p>
 
     <p>Sometimes, however, it can be useful to save all calls, even
-      tail-recursive calls. That can be done with the 'Stack On, Tail'
-      option. Note that this option will consume more memory and slow
-      down execution of interpreted functions when there are many
-      tail-recursive calls.
-    </p>
-
-    <p>It is also possible to turn off the Debugger stack trace
-      facility ('Stack Off'). <em>Note:</em> If an error occurs, in this
-      case the stack trace will be empty.</p>
-
-    <p>See the section about <seealso marker="#monitor">the Monitor
-      Window</seealso> for information about how to change the stack
-      trace option.</p>
+      tail-recursive calls. This is done with option
+      <em>Stack On, Tail</em>. Notice that this option consumes more
+      memory and slows down execution of interpreted functions when there
+      are many tail-recursive calls.</p>
+
+    <p>To turn off the Debugger stack trace facility, select option
+      <em>Stack Off</em>.</p>
+
+    <note>
+      <p>If an error occurs, the stack trace becomes empty in this
+        case.</p>
+    </note>
+
+    <p>For information about how to change the stack trace option, see
+      section <seealso marker="#monitor">Monitor Window</seealso>.</p>
   </section>
 
   <section>
     <marker id="monitor"/>
-    <title>The Monitor Window</title>
+    <title>Monitor Window</title>
+
+    <p>The Monitor window is the main window of Debugger and displays the
+      following:</p>
 
-    <p>The Monitor window is the main window of Debugger and shows a
-      listbox containing the names of all interpreted modules
-      (double-clicking a module brings up the View Module window),
-      which options are selected, and information about all debugged
-      processes, that is all processes which have been/are executing
-      code in interpreted modules.</p>
+    <list type="bulleted">
+      <item><p>A listbox containing the names of all interpreted
+        modules</p>
+        <p>Double-clicking a module brings up the View Module window.</p>
+      </item>
+      <item><p>Which options are selected</p></item>
+      <item><p>Information about all debugged processes, that is, all
+        processes that have been or are executing code in interpreted
+        modules</p></item>
+      </list>
 
     <image file="images/monitor.jpg">
-      <icaption>The Monitor Window.</icaption>
+      <icaption>Monitor Window</icaption>
     </image>
 
-    <p>The Auto Attach buttons, Stack Trace label, Back Trace Size
-      label, and Strings button show some options set, see
-      <seealso marker="#options">Options Menu</seealso> for further
-      information about these options.</p>
+    <p>The <em>Auto Attach</em> boxes, <em>Stack Trace</em> label,
+      <em>Back Trace Size</em> label, and <em>Strings</em> box display
+      some options set. For details about these options, see section
+      <seealso marker="#options">Options Menu</seealso>.</p>
 
     <section>
       <title>Process Grid</title>
-
       <taglist>
 	<tag><em>Pid</em></tag>
 	<item><p>The process identifier.</p></item>
-	
+
 	<tag><em>Initial Call</em></tag>
 	<item><p>The first call to an interpreted function by this
-	    process. (<c>Module:Function/Arity</c>)</p></item>
+          process. (<c>Module:Function/Arity</c>)</p></item>
 
 	<tag><em>Name</em></tag>
-	<item><p>The registered name, if any. If a registered name does
-	    not show up, it may be that the Debugger received
-	    information about the process before the name had been
-	    registered. Try selecting <em>Edit->Refresh</em>.</p></item>
+	<item><p>The registered name, if any. If a registered name is not
+          displayed, it can be that Debugger received information about
+          the process before the name was registered. Try selecting
+          <em>Edit > Refresh</em>.</p></item>
 
 	<tag><em>Status</em></tag>
 	<item><p>The current status, one of the following:</p>
 	  <taglist>
 	    <tag><em>idle</em></tag>
-	    <item><p>The interpreted function call has returned a value,
-		and the process is no longer executing interpreted code.
-	      </p></item>
+	    <item><p>The interpreted function call has returned a value, and
+	      the process is no longer executing interpreted code.</p></item>
 
 	    <tag><em>running</em></tag>
 	    <item><p>The process is running.</p></item>
-	    
+
 	    <tag><em>waiting</em></tag>
 	    <item><p>The process is waiting in a <c>receive</c>
-		statement.</p></item>
-	    
+	      statement.</p></item>
+
 	    <tag><em>break</em></tag>
 	    <item><p>The process is stopped at a breakpoint.</p></item>
-	    
+
 	    <tag><em>exit</em></tag>
 	    <item><p>The process has terminated.</p></item>
-	    
+
 	    <tag><em>no_conn</em></tag>
 	    <item><p>There is no connection to the node where
-		the process is located.</p></item>
+	      the process is located.</p></item>
 	  </taglist>
 	</item>
 
 	<tag><em>Information</em></tag>
-	<item><p>Additional information, if any. If the process is
-	    stopped at a breakpoint, the field contains information
-	    about the location <c>{Module,Line}</c>. If the process has
-	    terminated, the field contains the exit reason.</p></item>
+	<item><p>More information, if any. If the process is
+	  stopped at a breakpoint, the field contains information
+	  about the location <c>{Module,Line}</c>. If the process has
+	  terminated, the field contains the exit reason.</p></item>
       </taglist>
     </section>
 
     <section>
-      <title>The File Menu</title>
-      
+      <title>File Menu</title>
+
       <taglist>
 	<tag><em>Load Settings...</em></tag>
-	<item>
-	  <p>Try to load and restore Debugger settings from a file
-	    previously saved using <em>Save Settings...</em>, see below.
-	    Any errors are silently ignored.
-            <em>Note:</em> Settings saved by Erlang R16B01 or later
-            cannot be read by Erlang R16B or earlier.</p>
+	<item><p>Tries to load and restore Debugger settings from a file
+	  previously saved using <em>Save Settings...</em> (see below).
+	  Any errors are silently ignored.</p>
+	<p>Notice that settings saved by Erlang/OTP R16B01 or later
+	  cannot be read by Erlang/OTP R16B or earlier.</p>
 	</item>
-	
+
 	<tag><em>Save Settings...</em></tag>
-	<item><p>Save Debugger settings to a file. The settings include
-	    the set of interpreted files, breakpoints, and the selected
-	    options. The settings can be restored in a later Debugger
-	    session using <em>Load Settings...</em>, see above.
-	    Any errors are silently ignored.</p>
+	<item><p>Saves Debugger settings to a file. The settings include
+	  the set of interpreted files, breakpoints, and the selected
+	  options. The settings can be restored in a later Debugger
+	  session using <em>Load Settings...</em> (see above).
+	  Any errors are silently ignored.</p>
 	</item>
-	
+
 	<tag><em>Exit</em></tag>
-	<item><p>Stop Debugger.</p></item>
+	<item><p>Stops Debugger.</p></item>
       </taglist>
     </section>
 
     <section>
-      <title>The Edit Menu</title>
+      <title>Edit Menu</title>
       <taglist>
 	<tag><em>Refresh</em></tag>
-	<item><p>Update information about debugged processes. Removes
-	    information about all terminated processes from the window,
-	    and also closes all Attach Process windows for terminated
-	    processes.</p></item>
+	<item><p>Updates information about debugged processes. Information
+	  about all terminated processes are removed from the window. All
+	  Attach Process windows for terminated processes are closed.</p></item>
 
 	<tag><em>Kill All</em></tag>
-	<item><p>Terminate all processes listed in the window using
-	    <c>exit(Pid,kill)</c>.</p></item>
+	<item><p>Terminates all processes listed in the window using
+	  <c>exit(Pid,kill)</c>.</p></item>
       </taglist>
     </section>
 
     <section>
-      <title>The Module Menu</title>
+      <title>Module Menu</title>
       <taglist>
 	<tag><em>Interpret...</em></tag>
-	<item><p>Open the <seealso marker="#interpret">Interpret Dialog
-	      window</seealso> where new modules to be interpreted can
-	    be specified.</p></item>
-	
+	<item><p>Opens the
+	  <seealso marker="#interpret">Interpret Modules window</seealso>,
+	  where new modules to be interpreted can be specified.</p></item>
+
 	<tag><em>Delete All</em></tag>
-	<item><p>Stop interpreting all modules. Processes executing in
-	    interpreted modules will terminate.</p></item>
+	<item><p>Stops interpreting all modules. Processes executing in
+	  interpreted modules terminate.</p></item>
       </taglist>
 
       <p>For each interpreted module, a corresponding entry is added to
-	the Module menu, with the following submenu:</p>
+        the <em>Module</em> menu, with the following submenu:</p>
       <taglist>
 	<tag><em>Delete</em></tag>
-	<item><p>Stop interpreting the selected module. Processes
-	    executing in this module will terminate.</p></item>
-	
+	<item><p>Stops interpreting the selected module. Processes
+	  executing in this module terminate.</p></item>
+
 	<tag><em>View</em></tag>
-	<item><p>Open a <seealso marker="#view">View Module
-	      window</seealso> showing the contents of the selected
-	    module.</p></item>
+	<item><p>Opens a
+	  <seealso marker="#view">View Module window</seealso>, displaying the
+	  contents of the selected module.</p></item>
       </taglist>
     </section>
 
     <section>
-      <title>The Process Menu</title>
+      <title>Process Menu</title>
       <p>The following menu items apply to the currently selected
-	process, provided it is stopped at a breakpoint. See the chapter
-	about the <seealso marker="#attach">Attach Process
-	  window</seealso> for more information.</p>
+        process, provided it is stopped at a breakpoint (for details, see
+	section 
+	<seealso marker="#attach">Attach Process window</seealso>):</p>
       <taglist>
 	<tag><em>Step</em></tag><item></item>
 	<tag><em>Next</em></tag><item></item>
 	<tag><em>Continue</em></tag><item></item>
 	<tag><em>Finish</em></tag><item></item>
       </taglist>
+
       <p>The following menu items apply to the currently selected
-	process.</p>
+        process:</p>
       <taglist>
 	<tag><em>Attach</em></tag>
-	<item><p>Attach to the process and open a
-	    <seealso marker="#attach">Attach Process window</seealso>.
-	  </p></item>
-	
+	<item><p>Attaches to the process and open an
+	  <seealso marker="#attach">Attach Process window</seealso>.</p></item>
+
 	<tag><em>Kill</em></tag>
-	<item><p>Terminate the process using <c>exit(Pid,kill)</c>.</p>
-	</item>
+	<item><p>Terminates the process using <c>exit(Pid,kill)</c>.</p></item>
       </taglist>
     </section>
 
-  <section>
-    <title>The Break Menu</title>
-      <p>The items in this menu are used to create and delete
-	breakpoints.
-	See the <seealso marker="#breakpoints">Breakpoints</seealso>
-	chapter for more information.</p>
+    <section>
+      <title>Break Menu</title>
+      <p>The items in this menu are used to create and delete breakpoints.
+        For details, see section
+	<seealso marker="#breakpoints">Breakpoints</seealso>.</p>
+
       <taglist>
 	<tag><em>Line Break...</em></tag>
-	<item><p>Set a line breakpoint.</p></item>
+	<item><p>Sets a line breakpoint.</p></item>
 
 	<tag><em>Conditional Break...</em></tag>
-	<item><p>Set a conditional breakpoint.</p></item>
+	<item><p>Sets a conditional breakpoint.</p></item>
 
 	<tag><em>Function Break...</em></tag>
-	<item><p>Set a function breakpoint.</p></item>
+	<item><p>Sets a function breakpoint.</p></item>
 
 	<tag><em>Enable All</em></tag>
-	<item><p>Enable all breakpoints.</p></item>
+	<item><p>Enables all breakpoints.</p></item>
 
 	<tag><em>Disable All</em></tag>
-	<item><p>Disable all breakpoints.</p></item>
+	<item><p>Disables all breakpoints.</p></item>
 
-      <tag><em>Delete All</em></tag>
-	<item><p>Remove all breakpoints.</p></item>
+	<tag><em>Delete All</em></tag>
+	<item><p>Removes all breakpoints.</p></item>
       </taglist>
 
-      <p>For each breakpoint, a corresponding entry is added to
-      the Break
-	menu, from which it is possible to disable/enable or delete
-	the breakpoint,	and to change its trigger action.</p>
+      <p>For each breakpoint, a corresponding entry is added to the
+        <em>Break</em> menu, from which it is possible to disable, enable,
+	or delete the breakpoint, and to change its trigger action.</p>
     </section>
 
     <section>
       <marker id="options"/>
-      <title>The Options Menu</title>
+      <title>Options Menu</title>
 
       <taglist>
 	<tag><em>Trace Window</em></tag>
-	<item><p>Set which areas should be visible in
-	    an <seealso marker="#attach">Attach Process
-	      window</seealso>. Does not affect already existing
-	    Attach Process windows.</p>
+	<item><p>Sets the areas to be visible in an
+	  <seealso marker="#attach">Attach Process window</seealso>.
+	  Does not affect existing Attach Process windows.</p>
 	</item>
 
 	<tag><em>Auto Attach</em></tag>
-	<item><p>Set at which events a debugged process should be
-	    automatically attached to. Affects existing debugged
-	    processes.</p>
-	  <list>
-	    <item><em>First Call</em> - the first time a process calls a
-	      function in an interpreted module.</item>
-	    <item><em>On Exit</em> - at process termination.</item>
-	    <item><em>On Break</em> - when a process reaches a
-	      breakpoint.</item>
+	<item><p>Sets the events a debugged process is to be attached
+	  to automatically. Affects existing debugged processes.</p>
+	  <list type="bulleted">
+	    <item><p><em>First Call</em> - The first time a process calls
+	      a function in an interpreted module.</p></item>
+	    <item><p><em>On Exit</em> - At process termination.</p></item>
+	    <item><p><em>On Break</em> - When a process reaches a
+	      breakpoint.</p></item>
 	  </list>
 	</item>
 
 	<tag><em>Stack Trace</em></tag>
-	<item><p>Set stack trace option, see section
+	<item><p>Sets the stack trace option, see section
 	  <seealso marker="#stack_trace">Stack Trace</seealso>. Does not
-	    affect already existing debugged processes.</p>
-	  <list>
-	    <item><em>Stack On, Tail</em> - save information about all
-	      current calls.</item>
-	    <item><em>Stack On, No Tail</em> - save information about
+	    affect existing debugged processes.</p>
+	  <list type="bulleted">
+	    <item><p><em>Stack On, Tail</em> - Saves information about all
+	      current calls.</p></item>
+	    <item><p><em>Stack On, No Tail</em> - Saves information about
 	      current calls, discarding previous information when a tail
-	      recursive call is made.</item>
-	    <item><em>Stack Off</em> - do not save any information about
-	      current calls.</item>
+	      recursive call is made.</p></item>
+	    <item><p><em>Stack Off</em> - Does not save any information about
+	      current calls.</p></item>
 	  </list>
 	</item>
 
 	<tag><em>Strings</em></tag>
-	<item><p>Set which integer lists should be printed as strings.
-            Does not affect already existing debugged processes.</p>
-	  <list>
-
-	    <item><em>Use range of +pc flag</em> - use the printable
-              character range set by the
-              <seealso marker="erts:erl#printable_character_range">
-              <c>erl(1)</c></seealso> flag <c>+pc</c>.
-          </item>
+	<item><p>Sets the integer lists to be printed as strings.
+	  Does not affect existing debugged processes.</p>
+	  <list type="bulleted">
+	    <item><p><em>Use range of +pc flag</em> - Uses the printable
+	      character range set by the <c>erl(1)</c> flag
+	      <seealso marker="erts:erl#printable_character_range"><c>+pc</c></seealso>.</p>
+	    </item>
 	  </list>
 	</item>
 
 	<tag><em>Back Trace Size...</em></tag>
-	<item><p>Set how many call frames should be fetched when
-	    inspecting the call stack from the Attach Process window.
-	    Does not affect already existing Attach Process windows.</p>
+	<item><p>Sets how many call frames to be fetched when
+	  inspecting the call stack from the Attach Process window.
+	  Does not affect existing Attach Process windows.</p>
 	</item>
       </taglist>
     </section>
 
     <section>
-      <title>The Windows Menu</title>
+      <title>Windows Menu</title>
       <p>Contains a menu item for each open Debugger window. Selecting
-	one of the items will raise the corresponding window.</p>
+        one of the items raises the corresponding window.</p>
     </section>
 
     <section>
-      <title>The Help Menu</title>
+      <title>Help Menu</title>
       <taglist>
 	<tag><em>Help</em></tag>
-	<item><p>View the Debugger documentation. Currently this
-	    function requires a web browser to be up and running.</p></item>
+	<item><p>Shows the Debugger documentation. This function requires a
+	  web browser.</p></item>
       </taglist>
     </section>
   </section>
-    
+
   <section>
     <marker id="interpret"/>
-    <title>The Interpret Dialog Window</title>
+    <title>Interpret Modules Window</title>
 
-    <p>The interpret dialog module is used for selecting which modules
-      to interpret. Initially, the window shows the modules (<c>erl</c>
-      files) and subdirectories of the current working directory.</p>
+    <p>The Interpret Modules window is used for selecting which modules
+      to interpret. Initially, the window displays the modules (<c>erl</c>
+     files) and subdirectories of the current working directory.</p>
 
-    <p>Interpretable modules are modules for which a BEAM file, compiled
-      with the option <c>debug_info</c> set, can be found in the same
+    <p>Interpretable modules are modules for which a <c>.beam</c> file,
+      compiled with option <c>debug_info</c> set, is located in the same
       directory as the source code, or in an <c>ebin</c> directory next
       to it.</p>
 
-    <p>Modules, for which the above requirements are not fulfilled, are
-      not interpretable and are therefore displayed within parentheses.
-    </p>
+    <p>Modules for which these requirements are not fulfilled are
+      not interpretable and are therefore displayed within parentheses.</p>
 
-    <p>The <c>debug_info</c> option causes <em>debug information</em> or
-      <em>abstract code</em> to be added to the BEAM file. This will
-      increase the size of the file, and also makes it possible to
+    <p>Option <c>debug_info</c> causes <em>debug information</em> or
+      <em>abstract code</em> to be added to the <c>.beam</c> file.
+      This increases the file size and makes it possible to
       reconstruct the source code. It is therefore recommended not to
       include debug information in code aimed for target systems.</p>
 
     <p>An example of how to compile code with debug information using
-      <c>erlc</c>:<br/>
-      <c>% erlc +debug_info module.erl</c></p>
-      
+      <c>erlc</c>:</p>
+    <pre>
+% erlc +debug_info module.erl</pre>
+
     <p>An example of how to compile code with debug information from
-      the Erlang shell:<br/>
-      <c>4> c(module, debug_info).</c></p>
-      
+      the Erlang shell:</p>
+    <pre>
+4> c(module, debug_info).</pre>
+
     <image file="images/interpret.jpg">
-      <icaption>The Interpret Dialog Window.</icaption>
+      <icaption>Interpret Modules Window</icaption>
     </image>
 
-    <p>Browse the file hierarchy and interpret the appropriate modules
-      by selecting a module name and pressing <em>Choose</em> (or
-      carriage return), or by double clicking the module name.
-      Interpreted modules have the type <c>erl src</c>.
-    </p>
+    <p>To browse the file hierarchy and interpret the appropriate modules,
+      either select a module name and click <em>Choose</em> (or
+      press carriage return), or double-click the module name.
+      Interpreted modules have the type <c>erl src</c>.</p>
 
-    <p>Pressing <em>All</em> will interpret all displayed modules in
-      the chosen directory.</p>
+    <p>To interpret all displayed modules in the chosen directory, click
+      <em>All</em>.</p>
 
-    <p>Pressing <em>Done</em> will close the window.</p>
+    <p>To close the window, click <em>Done</em>.</p>
 
     <note>
-      <p>When the Debugger is started in global mode (which is
-	the default, see
-	<seealso marker="debugger:debugger#start/0">debugger:start/0</seealso>),
-	modules added (or deleted) for interpretation will be added (or
-	deleted) on all known Erlang nodes.</p>
+      <p>When Debugger is started in global mode (which is the default, see
+        <seealso marker="debugger#start/0">debugger:start/0</seealso>),
+        modules added (or deleted) for interpretation are added (or
+        deleted) on all known Erlang nodes.</p>
     </note>
   </section>
 
   <section>
     <marker id="attach"/>
-    <title>The Attach Process Window</title>
+    <title>Attach Process Window</title>
 
-    <p>From an Attach Process window the user can interact with a
+    <p>From an Attach Process window, you can interact with a
       debugged process. One window is opened for each process that has
-      been attached to. Note that when attaching to a process, its
-      execution is automatically stopped.
-    </p>
+      been attached to. Notice that when attaching to a process, its
+      execution is automatically stopped.</p>
 
     <image file="images/attach.jpg">
-      <icaption>The Attach Process Window.</icaption>
+      <icaption>Attach Process Window</icaption>
     </image>
 
-    <p>The window is divided into five parts:</p>
-    <list>
-      <item><p>The Code area, showing the code being executed. The code
-	  is indented and each line is prefixed with its line number.
-	  If the process execution is stopped, the current line is
-	  marked with <em>--></em>. An existing break point at a line
-	  is marked with a stop symbol. In the example above,
-	  the execution has been stopped at line 6, before
-	  the execution of <c>fac/1</c>.</p>
-	<p>Active breakpoints are shown in red, while inactive
-	  breakpoints are shown in blue.</p>
+    <p>The window is divided into the following five parts:</p>
+    <list type="bulleted">
+      <item><p>The Code area, displaying the code being executed. The code
+        is indented and each line is prefixed with its line number.
+        If the process execution is stopped, the current line is
+        marked with <c>--></c>. An existing break point at a line
+        is marked with a stop symbol. In the example shown in the
+        illustration, the execution stopped at line 6, before
+        the execution of <c>fac/1</c>.</p>
+
+        <p>Active breakpoints are displayed in red and inactive
+          breakpoints in blue.</p>
       </item>
-      <item>The Button area, with buttons for quick access to frequently
-	used functions in the Process menu.</item>
-      <item>The Evaluator area, where the user can evaluate functions
-	within the context of the debugged process, provided that
-	process execution has been stopped.</item>
-      <item>The Bindings area, showing all variables bindings.
-	Clicking on a variable name will result in the value being
-	displayed in the Evaluator area.
-	Double-clicking on a variable name will open a window where
-	the variable value may be edited. Note however that pid,
-	reference, binary or port values can not be edited.
+
+      <item><p>The Button area, with buttons for quick access to frequently
+        used functions in the <em>Process</em> menu.</p></item>
+
+      <item><p>The Evaluator area, where you can evaluate functions
+        within the context of the debugged process, if that
+        process execution is stopped.</p></item>
+
+      <item><p>The Bindings area, displaying all variables bindings. If you
+        click a variable name, the value is displayed in the Evaluator area.
+	Double-click a variable name to open a window where
+        the variable value can be edited. Notice however that pid,
+        reference, binary, or port values cannot be edited.</p>
       </item>
-      <item><p>The Trace area, showing a trace output for the process.
-	</p>
+
+      <item><p>The Trace area, which displays a trace output for the
+        process.</p>
 	<taglist>
-	  <tag><c>++ (N) &lt;L&gt;</c></tag>
-	  <item>Function call, where <c>N</c> is the call level and
-	    <c>L</c> the line number.</item>
+          <tag><c>++ (N) &lt;L&gt;</c></tag>
+          <item><p>Function call, where <c>N</c> is the call level and
+            <c>L</c> the line number.</p></item>
 
-	  <tag><c>-- (N)</c></tag>
-	  <item>Function return value.</item>
+          <tag><c>-- (N)</c></tag>
+          <item><p>Function return value</p>.</item>
 
-	  <tag><c>==> Pid : Msg</c></tag>
-	  <item>The message <c>Msg</c> is sent to process <c>Pid</c>.
-	  </item>
+          <tag><c>==> Pid : Msg</c></tag>
+          <item><p>The message <c>Msg</c> is sent to process
+            <c>Pid</c>.</p></item>
 
-	  <tag><c><![CDATA[<== Msg]]></c></tag>
-	  <item>The message <c>Msg</c> is received.</item>
+          <tag><c><![CDATA[<== Msg]]></c></tag>
+          <item><p>The message <c>Msg</c> is received.</p></item>
 
-	  <tag><c>++ (N) receive</c></tag>
-	  <item>Waiting in a <c>receive</c>.</item>
+          <tag><c>++ (N) receive</c></tag>
+          <item><p>Waiting in a <c>receive</c>.</p></item>
 
-	  <tag><c>++ (N) receive with timeout</c></tag>
-	  <item>Waiting in a <c>receive...after</c>.</item>
-	</taglist>
+          <tag><c>++ (N) receive with timeout</c></tag>
+          <item><p>Waiting in a <c>receive...after</c>.</p></item>
+        </taglist>
 
-	<p>Also the back trace, a summary of the current function calls
-	  on the stack, is displayed in the Trace area.</p>
+        <p>The Trace area also displays Back Trace, a summary of the
+          current function calls on the stack.</p>
       </item>
     </list>
 
-    <p>It is configurable using the Options menu which areas should
-      be shown or hidden. By default, all areas except the Trace area
-      are shown.</p>
+    <p>Using the <em>Options</em> menu, you can set which areas to be
+      displayed. By default, all areas except the Trace area are displayed.</p>
 
     <section>
-      <title>The File Menu</title>
+      <title>File Menu</title>
 
       <taglist>
 	<tag><em>Close</em></tag>
-	<item><p>Close this window and detach from the process.</p>
+	<item><p>Closes this window and detach from the process.</p>
 	</item>
       </taglist>
     </section>
 
     <section>
-      <title>The Edit Menu</title>
+      <title>Edit Menu</title>
 
       <taglist>
 	<tag><em>Go to line...</em></tag>
-	<item><p>Go to a specified line number.</p></item>
+	<item><p>Goes to a specified line number.</p></item>
 
 	<tag><em>Search...</em></tag>
-	<item><p>Search for a specified string.</p></item>
+	<item><p>Searches for a specified string.</p></item>
       </taglist>
     </section>
 
     <section>
-      <title>The Process Menu</title>
+      <title>Process Menu</title>
 
       <taglist>
 	<tag><em>Step</em></tag> 
-	<item><p>Execute the current line of code, stepping into any
+	<item><p>Executes the current code line, stepping into any
 	    (interpreted) function calls.</p></item>
 
 	<tag><em>Next</em></tag>
-	<item><p>Execute the current line of code and stop at the next
+	<item><p>Executes the current code line and stop at the next
 	    line.</p></item>
 
 	<tag><em>Continue</em></tag>
-	<item><p>Continue the execution.</p></item>
+	<item><p>Continues the execution.</p></item>
 
 	<tag><em>Finish</em></tag>
-	<item><p>Continue the execution until the current function
+	<item><p>Continues the execution until the current function
 	    returns.</p></item>
 
 	<tag><em>Skip</em></tag>
-	<item><p>Skip the current line of code and stop at the next
+	<item><p>Skips the current code line and stop at the next
 	    line. If used on the last line in a function body,
-	    the function will return <c>skipped</c>.</p></item>
+	    the function returns <c>skipped</c>.</p></item>
 
 	<tag><em>Time Out</em></tag>
-	<item><p>Simulate a timeout when executing a
+	<item><p>Simulates a time-out when executing a
 	    <c>receive...after</c> statement.</p></item>
 
 	<tag><em>Stop</em></tag>
-	<item><p>Stop the execution of a running process, that is, make
-	    the process stop as at a breakpoint. The command will take
+	<item><p>Stops the execution of a running process, that is, make
+	    the process stop at a breakpoint. The command takes
 	    effect (visibly) the next time the process receives a
 	    message.</p></item>
 
 	<tag><em>Where</em></tag>
-	<item><p>Make sure the current location of the execution is
+	<item><p>Verifies that the current location of the execution is
 	    visible in the code area.</p></item>
 
 	<tag><em>Kill</em></tag>
-	<item><p>Terminate the process using <c>exit(Pid,kill)</c>.</p>
+	<item><p>Terminates the process using <c>exit(Pid,kill)</c>.</p>
 	</item>
 
 	<tag><em>Messages</em></tag>
-	<item><p>Inspect the message queue of the process. The queue is
-	    printed in the evaluator area.</p></item>
+	<item><p>Inspects the message queue of the process. The queue is
+	    displayed in the Evaluator area.</p></item>
 
 	<tag><em>Back Trace</em></tag>
-	<item><p>Display the back trace of the process, a summary of
-	    the current function calls on the stack, in the trace area.
-	    Requires that the Trace area is visible and that the stack
-	    trace option is 'Stack On, Tail' or 'Stack On, No Tail'.</p>
+	<item><p>Displays the back trace of the process, a summary of
+	    the current function calls on the stack, in the Trace area.
+	    Requires that the Trace area is visible and that the Stack
+	    Trace option is <em>Stack On, Tail</em> or
+	    <em>Stack On, No Tail</em>.</p>
 	</item>
 
 	<tag><em>Up</em></tag>
-	<item><p>Inspect the previous function call on the stack,
+	<item><p>Inspects the previous function call on the stack,
 	    showing the location and variable bindings.</p></item>
 
 	<tag><em>Down</em></tag>
-	<item><p>Inspect the next function call on the stack, showing
+	<item><p>Inspects the next function call on the stack, showing
 	    the location and variable bindings.</p></item>
       </taglist>
     </section>
 
     <section>
-      <title>The Options Menu</title>
+      <title>Options Menu</title>
 
       <taglist>
 	<tag><em>Trace Window</em></tag>
-	<item><p>Set which areas should be visible. Does not affect
-	    other Attach Process windows.</p>
-	</item>
+	<item><p>Sets which areas are to be visible. Does not affect
+	    other Attach Process windows.</p></item>
 
 	<tag><em>Stack Trace</em></tag>
-	<item><p>Same as in <seealso marker="#monitor">the Monitor
-	      window</seealso>, but only affects the debugged
-	    process the window is attached to.</p>
-	</item>
+	<item><p>Same as in the <seealso marker="#monitor">Monitor
+	    window</seealso>, but only affects the debugged
+	    process the window is attached to.</p></item>
 
 	<tag><em>Strings</em></tag>
-	<item><p>Same as in <seealso marker="#monitor">the Monitor
-	      window</seealso>, but only affects the debugged
-	    process the window is attached to.</p>
-	</item>
+	<item><p>Same as in the <seealso marker="#monitor">Monitor
+	    window</seealso>, but only affects the debugged
+	    process the window is attached to.</p></item>
 
 	<tag><em>Back Trace Size...</em></tag>
-	<item><p>Set how many call frames should be fetched when
+	<item><p>Sets how many call frames are to be fetched when
 	    inspecting the call stack. Does not affect other Attach
-	    Process windows.</p>
-	</item>
+	    Process windows.</p></item>
       </taglist>
     </section>
 
     <section>
-      <title>Break, Windows and Help Menus</title>
+      <title>Break, Windows, and Help Menus</title>
 
-      <p>The Break, Windows and Help menus look the same as in
-	the Monitor window, see the chapter
-	<seealso marker="#monitor">The Monitor Window</seealso>, except
-	that the Breaks menu apply to the local breakpoints only.</p>
+      <p>The <em>Break</em>, <em>Windows</em>, and <em>Help</em> menus
+        are the same as in the
+        <seealso marker="#monitor">Monitor Window</seealso>, except
+        that the <em>Breaks</em> menu applies only to local
+        breakpoints.</p>
     </section>
   </section>
 
   <section>
     <marker id="view"/>
-    <title>The View Module Window</title>
+    <title>View Module Window</title>
 
-    <p>The View Module window shows the contents of an interpreted
+    <p>The View Module window displays the contents of an interpreted
       module and makes it possible to set breakpoints.</p>
 
     <image file="images/view.jpg">
-      <icaption>The View Module Window.</icaption>
+      <icaption>View Module Window</icaption>
     </image>
 
     <p>The source code is indented and each line is prefixed with its
       line number.</p>
 
-    <p>Clicking a line will highlight it and select it to be the target
-      of the breakpoint functions available from the Break menu.
-      Doubleclicking a line will set a line breakpoint on that line.
-      Doubleclicking a line with an existing breakpoint will remove
-      the breakpoint.</p>
+    <p>Clicking a line highlights it and selects it to be the target
+      of the breakpoint functions available from the <em>Break</em> menu.
+      To set a line breakpoint on a line, double-click it.
+      To remove the breakpoint, double-click the line with an existing
+       breakpoint.</p>
 
     <p>Breakpoints are marked with a stop symbol.</p>
 
     <section>
       <title>File and Edit Menus</title>
-      <p>The File and Edit menus look the same as in the Attach Process
-	window, see the chapter <seealso marker="#attach">The Attach
-	  Process Window</seealso>.</p>
+      <p>The <em>File</em> and <em>Edit</em> menus are the same as in the
+      <seealso marker="#attach">Attach Process Window</seealso>.</p>
     </section>
 
     <section>
-      <title>Break, Windows and Help Menus</title>
+      <title>Break, Windows, and Help Menus</title>
 
-      <p>The Break, Windows and Help menus look the same as in
-	the Monitor window, see the chapter
-	<seealso marker="#monitor">The Monitor Window</seealso>, except
-	that the Breaks menu apply to the local breakpoints only.</p>
+      <p>The <em>Break</em>, <em>Windows</em>, and <em>Help</em> menus
+        are the same as in the
+        <seealso marker="#monitor">Monitor Window</seealso>, except
+	that the <em>Break</em> menu applies only to local breakpoints.</p>
     </section>
   </section>
 
@@ -862,14 +852,14 @@ c_break(Bindings) ->
     <title>Performance</title>
 
     <p>Execution of interpreted code is naturally slower than for
-      regularly compiled modules. Using the Debugger also increases
+      regularly compiled modules. Using Debugger also increases
       the number of processes in the system, as for each debugged
       process another process (the meta process) is created.</p>
 
-    <p>It is also worth to keep in mind that programs with timers may
+    <p>It is also worth to keep in mind that programs with timers can
       behave differently when debugged. This is especially true when
-      stopping the execution of a process, for example at a
-      breakpoint. Timeouts can then occur in other processes that
+      stopping the execution of a process (for example, at a
+      breakpoint). Time-outs can then occur in other processes that
       continue execution as normal.</p>
   </section>
 
@@ -878,8 +868,8 @@ c_break(Bindings) ->
 
     <p>Code loading works almost as usual, except that interpreted
       modules are also stored in a database and debugged processes
-      uses only this stored code. Re-interpreting an interpreted
-      module will result in the new version being stored as well, but
+      use only this stored code. Reinterpreting an interpreted
+      module results in the new version being stored as well, but
       does not affect existing processes executing an older version
       of the code. This means that the code replacement mechanism of
       Erlang does not work for debugged processes.</p>
@@ -888,22 +878,24 @@ c_break(Bindings) ->
   <section>
     <title>Debugging Remote Nodes</title>
 
-    <p>By using <c>debugger:start/1</c>, it can be specified if Debugger
-      should be started in local or global mode.</p>
+    <p>By using
+      <seealso marker="debugger#start/1">debugger:start/1</seealso>,
+      you can specify if Debugger is to be started in local or global
+      mode:</p>
     <pre>
 debugger:start(local | global)</pre>
-    <p>If no argument is provided, Debugger is started in global mode.
-    </p>
+
+    <p>If no argument is provided, Debugger starts in global mode.</p>
 
     <p>In local mode, code is interpreted only at the current node.
       In global mode, code is interpreted at all known nodes. Processes
-      at other nodes executing interpreted code will automatically be
-      shown in the Monitor window and can be attached to like any other
+      at other nodes executing interpreted code are automatically
+      displayed in the Monitor window and can be attached to like any other
       debugged process.</p>
 
-    <p>It is possible, but definitely not recommended to start Debugger
-      in global mode on more than one node in a network, as they will
-      interfere with each other leading to inconsistent behaviour.</p>
+    <p>It is possible, but definitely not recommended, to start Debugger
+      in global mode on more than one node in a network, as the nodes
+      interfere with each other, leading to inconsistent behavior.</p>
   </section>
 </chapter>
 
diff --git a/lib/debugger/doc/src/i.xml b/lib/debugger/doc/src/i.xml
index 9ceba94b44..db89f23494 100644
--- a/lib/debugger/doc/src/i.xml
+++ b/lib/debugger/doc/src/i.xml
@@ -4,7 +4,7 @@
 <erlref>
   <header>
     <copyright>
-      <year>1998</year><year>2013</year>
+      <year>1998</year><year>2016</year>
       <holder>Ericsson AB. All Rights Reserved.</holder>
     </copyright>
     <legalnotice>
@@ -29,35 +29,36 @@
     <rev></rev>
   </header>
   <module>i</module>
-  <modulesummary>Debugger/Interpreter Interface</modulesummary>
+  <modulesummary>Debugger/Interpreter Interface.</modulesummary>
   <description>
-    <p>The module <c>i</c> provides short forms for some of
+    <p>The <c>i</c> module provides short forms for some of
       the functions used by the graphical Debugger and some of
-      the functions in the <c>int</c> module, the Erlang interpreter.
-    </p>
+      the functions in module
+      <seealso marker="int"><c>int</c></seealso>, the Erlang interpreter.</p>
 
     <p>This module also provides facilities for displaying status
       information about interpreted processes and break points.</p>
 
     <p>It is possible to attach to interpreted processes by giving
       the corresponding process identity only. By default, an attachment
-      window pops up. Processes at other Erlang nodes can be
+      window is displayed. Processes at other Erlang nodes can be
       attached manually or automatically.</p>
 
-    <p>By preference, these functions can be included in the module
-      <c>shell_default</c>. By default, they are.</p>
+    <p>By preference, these functions can be included in module
+      <seealso marker="stdlib:shell_default"><c>stdlib:shell_default</c></seealso>.
+      By default, they are included in that module.</p>
   </description>
 
   <funcs>
     <func>
       <name>im() -> pid()</name>
-      <fsummary>Start a graphical monitor</fsummary>
+      <fsummary>Start a graphical monitor.</fsummary>
       <desc>
 	<p>Starts a new graphical monitor. This is the Monitor window,
-	  the main window of the Debugger. All of the Debugger and
+	  the main window of Debugger. All the Debugger and
 	  interpreter functionality is accessed from the Monitor window.
-	  The Monitor window displays the status of all processes that 
-	  have been/are executing interpreted modules.</p>
+	  This window displays the status of all processes that 
+	  have been or are executing interpreted modules.</p>
       </desc>
     </func>
 
@@ -66,7 +67,7 @@
       <name>ii(AbsModule) -> {module, Module} | error</name>
       <name>ini(AbsModules) -> ok</name>
       <name>ini(AbsModule) -> {module, Module} | error</name>
-      <fsummary>Interpret a module</fsummary>
+      <fsummary>Interpret a module.</fsummary>
       <type>
 	<v>AbsModules = [AbsModule]</v>
 	<v>AbsModule = Module | File</v>
@@ -85,7 +86,7 @@
     <func>
       <name>iq(AbsModule) -> ok</name>
       <name>inq(AbsModule) -> ok</name>
-      <fsummary>Stop interpreting a module</fsummary>
+      <fsummary>Stop interpreting a module.</fsummary>
       <type>
 	<v>AbsModule = Module | File</v>
 	<v>&nbsp;Module = atom()</v>
@@ -110,28 +111,27 @@
 
     <func>
       <name>ip() -> ok</name>
-      <fsummary>Make a printout of the current status of all interpreted
-	processes</fsummary>
+      <fsummary>Print the current status of all interpreted
+	processes.</fsummary>
       <desc>
-	<p>Makes a printout of the current status of all interpreted 
-	  processes.</p>
+	<p>Prints the current status of all interpreted processes.</p>
       </desc>
     </func>
 
     <func>
       <name>ic() -> ok</name>
       <fsummary>Clear information about processes executing interpreted
-	code</fsummary>
+	code.</fsummary>
       <desc>
 	<p>Clears information about processes executing interpreted code
-	  byt removing all information about terminated processes.</p>
+	  by removing all information about terminated processes.</p>
       </desc>
     </func>
 
     <func>
       <name>iaa(Flags) -> true</name>
       <name>iaa(Flags, Function) -> true</name>
-      <fsummary>Set when and how to attach to a process</fsummary>
+      <fsummary>Set when and how to attach to a process.</fsummary>
       <type>
 	<v>Flags = [init | break | exit]</v>
 	<v>Function = {Module,Name,Args}</v>
@@ -139,42 +139,41 @@
 	<v>&nbsp;Args = [term()]</v>
       </type>
       <desc>
-	<p>Sets when and how to automatically attach to a debugged
-	  process, see
+	<p>Sets when and how to attach to a debugged process
+          automatically, see
 	  <seealso marker="int#auto_attach/0">int:auto_attach/2</seealso>.
 	  <c>Function</c> defaults to the standard function used by
-	  the Debugger.</p>
+	  Debugger.</p>
       </desc>
     </func>
 
     <func>
       <name>ist(Flag) -> true</name>
-      <fsummary>Set how to save call frames</fsummary>
+      <fsummary>Set how to save call frames.</fsummary>
       <type>
 	<v>Flag = all | no_tail | false</v>
       </type>
       <desc>
 	<p>Sets how to save call frames in the stack, see
-	  <seealso marker="int#stack_trace/0">int:stack_trace/1</seealso>.
-	</p>
+	  <seealso marker="int#stack_trace/0">int:stack_trace/1</seealso>.</p>
       </desc>
     </func>
 
     <func>
       <name>ia(Pid) -> ok | no_proc</name>
-      <fsummary>Attach to a process</fsummary>
+      <fsummary>Attache to a process.</fsummary>
       <type>
 	<v>Pid = pid()</v>
       </type>
       <desc>
-	<p>Attaches to the debugged process <c>Pid</c>. A Debugger
+	<p>Attaches to the debugged process <c>Pid</c>. An
 	  Attach Process window is opened for the process.</p>
       </desc>
     </func>
 
     <func>
       <name>ia(X,Y,Z) -> ok | no_proc</name>
-      <fsummary>Attach to a process</fsummary>
+      <fsummary>Attache to a process.</fsummary>
       <type>
 	<v>X = Y = Z = int()</v>
       </type>
@@ -186,7 +185,7 @@
 
     <func>
       <name>ia(Pid, Function) -> ok | no_proc</name>
-      <fsummary>Attach to a process</fsummary>
+      <fsummary>Attache to a process.</fsummary>
       <type>
 	<v>Pid = pid()</v>
 	<v>Function = {Module,Name}</v>
@@ -194,14 +193,14 @@
       </type>
       <desc>
 	<p>Attaches to the debugged process <c>Pid</c>. The interpreter
-	  will call <c>spawn(Module, Name, [Pid])</c> (and ignore
+	  calls <c>spawn(Module, Name, [Pid])</c> (and ignores
 	  the result).</p>
       </desc>
     </func>
 
     <func>
       <name>ia(X,Y,Z, Function) -> ok | no_proc</name>
-      <fsummary>Attach to a process</fsummary>
+      <fsummary>Attache to a process.</fsummary>
       <type>
 	<v>X = Y = Z = int()</v>
 	<v>Function = {Module,Name}</v>
@@ -211,15 +210,15 @@
 	<p>Same as <c>ia(Pid, Function)</c>, where <c>Pid</c> is
 	  the result of calling the shell function <c>pid(X,Y,Z)</c>.
 	  An attached process is expected to call the unofficial
-	  <c>int:attached(Pid)</c> function and to be able to handle
-	  messages from the interpreter, see <c>dbg_wx_trace.erl</c> for
-	  an example.</p>
+	  function <c>int:attached(Pid)</c> and to be able to handle
+	  messages from the interpreter. For an example, see
+	  <c>dbg_wx_trace.erl</c>.</p>
       </desc>
     </func>
 
     <func>
       <name>ib(Module, Line) -> ok | {error, break_exists}</name>
-      <fsummary>Create a breakpoint</fsummary>
+      <fsummary>Create a breakpoint.</fsummary>
       <type>
 	<v>Module = atom()</v>
 	<v>Line = int()</v>
@@ -232,20 +231,20 @@
     <func>
       <name>ib(Module, Name, Arity) -> ok | {error, function_not_found}
       </name>
-      <fsummary>Create breakpoints in the specified function</fsummary>
+      <fsummary>Create breakpoints in the specified function.</fsummary>
       <type>
 	<v>Module = Name = atom()</v>
 	<v>Arity = int()</v>
       </type>
       <desc>
 	<p>Creates breakpoints at the first line of every clause of 
-	  the <c>Module:Name/Arity</c> function.</p>
+	  function <c>Module:Name/Arity</c>.</p>
       </desc>
     </func>
 
     <func>
       <name>ir() -> ok</name>
-      <fsummary>Delete all breakpoints</fsummary>
+      <fsummary>Delete all breakpoints.</fsummary>
       <desc>
 	<p>Deletes all breakpoints.</p>
       </desc>
@@ -253,7 +252,7 @@
 
     <func>
       <name>ir(Module) -> ok</name>
-      <fsummary>Delete all breakpoints in a module</fsummary>
+      <fsummary>Delete all breakpoints in a module.</fsummary>
       <type>
 	<v>Module = atom()</v>
       </type>
@@ -264,61 +263,57 @@
 
     <func>
       <name>ir(Module, Line) -> ok</name>
-      <fsummary>Delete a breakpoint</fsummary>
+      <fsummary>Delete a breakpoint.</fsummary>
       <type>
 	<v>Module = atom()</v>
 	<v>Line = int()</v>
       </type>
       <desc>
-	<p>Deletes the breakpoint located at <c>Line</c> in
-	  <c>Module</c>.</p>
+	<p>Deletes the breakpoint at <c>Line</c> in <c>Module</c>.</p>
       </desc>
     </func>
 
     <func>
       <name>ir(Module, Name, Arity) -> ok | {error, function_not_found}
       </name>
-      <fsummary>Delete breakpoints from the specified function
-      </fsummary>
+      <fsummary>Delete breakpoints from the specified function.</fsummary>
       <type>
 	<v>Module = Name = atom()</v>
 	<v>Arity = int()</v>
       </type>
       <desc>
 	<p>Deletes the breakpoints at the first line of every clause of 
-	  the <c>Module:Name/Arity</c> function.</p>
+	  function <c>Module:Name/Arity</c>.</p>
       </desc>
     </func>
 
     <func>
       <name>ibd(Module, Line) -> ok</name>
-      <fsummary>Make a breakpoint inactive</fsummary>
+      <fsummary>Make a breakpoint inactive.</fsummary>
       <type>
 	<v>Module = atom()</v>
 	<v>Line = int()</v>
       </type>
       <desc>
-	<p>Makes the breakpoint at <c>Line</c> in <c>Module</c>
-	  inactive.</p>
+	<p>Makes the breakpoint at <c>Line</c> in <c>Module</c> inactive.</p>
       </desc>
     </func>
 
     <func>
       <name>ibe(Module, Line) -> ok</name>
-      <fsummary>Make a breakpoint active</fsummary>
+      <fsummary>Make a breakpoint active.</fsummary>
       <type>
 	<v>Module = atom()</v>
 	<v>Line = int()</v>
       </type>
       <desc>
-	<p>Makes the breakpoint at <c>Line</c> in <c>Module</c> active.
-	</p>
+	<p>Makes the breakpoint at <c>Line</c> in <c>Module</c> active.</p>
       </desc>
     </func>
 
     <func>
       <name>iba(Module, Line, Action) -> ok</name>
-      <fsummary>Set the trigger action of a breakpoint</fsummary>
+      <fsummary>Set the trigger action of a breakpoint.</fsummary>
       <type>
 	<v>Module = atom()</v>
 	<v>Line = int()</v>
@@ -332,7 +327,7 @@
 
     <func>
       <name>ibc(Module, Line, Function) -> ok</name>
-      <fsummary>Set the conditional test of a breakpoint</fsummary>
+      <fsummary>Set the conditional test of a breakpoint.</fsummary>
       <type>
 	<v>Module = atom()</v>
 	<v>Line = int()</v>
@@ -346,46 +341,44 @@
 	<p>The conditional test is performed by calling
 	  <c>Module:Name(Bindings)</c>, where <c>Bindings</c> is
 	  the current variable bindings. The function must return
-	  <c>true</c> (break) or <c>false</c> (do not break). Use
-	  <c>int:get_binding(Var, Bindings)</c> to retrieve the value
-	  of a variable <c>Var</c>.</p>
+	  <c>true</c> (break) or <c>false</c> (do not break).
+	  To retrieve the value of a variable <c>Var</c>, use
+	  <seealso marker="int#get_binding/2">int:get_binding(Var, Bindings)</seealso>.</p>
       </desc>
     </func>
 
     <func>
       <name>ipb() -> ok</name>
-      <fsummary>Make a printout of all existing breakpoints</fsummary>
+      <fsummary>Print all existing breakpoints.</fsummary>
       <desc>
-	<p>Makes a printout of all existing breakpoints.</p>
+	<p>Prints all existing breakpoints.</p>
       </desc>
     </func>
 
     <func>
       <name>ipb(Module) -> ok</name>
-      <fsummary>Make a printout of all breakpoints in a module
-      </fsummary>
+      <fsummary>Print all existing breakpoints in a module.</fsummary>
       <type>
 	<v>Module = atom()</v>
       </type>
       <desc>
-	<p>Makes a printout of all existing breakpoints in
-	  <c>Module</c>.</p>
+	<p>Prints all existing breakpoints in <c>Module</c>.</p>
       </desc>
     </func>
 
     <func>
       <name>iv() -> atom()</name>
-      <fsummary>Current version number of the interpreter</fsummary>
+      <fsummary>Return the current version number of the interpreter.
+      </fsummary>
       <desc>
 	<p>Returns the current version number of the interpreter.
-	  The same as the version number of the Debugger application.
-	</p>
+	  Same as the version number of the <c>Debugger</c> application.</p>
       </desc>
     </func>
 
     <func>
       <name>help() -> ok</name>
-      <fsummary>Print help text</fsummary>
+      <fsummary>Print help text.</fsummary>
       <desc>
 	<p>Prints help text.</p>
       </desc>
@@ -393,15 +386,8 @@
   </funcs>
 
   <section>
-    <title>Usage</title>
-
-    <p>Refer to the Debugger User's Guide for information about
-      the Debugger.</p>
-  </section>
-
-  <section>
   <title>See Also</title>
-    <p><c>int(3)</c></p>
+    <p><seealso marker="int"><c>int(3)</c></seealso></p>
   </section>
 </erlref>
 
diff --git a/lib/debugger/doc/src/int.xml b/lib/debugger/doc/src/int.xml
index ea21d04a07..31e9dfe923 100644
--- a/lib/debugger/doc/src/int.xml
+++ b/lib/debugger/doc/src/int.xml
@@ -4,7 +4,7 @@
 <erlref>
   <header>
     <copyright>
-      <year>1998</year><year>2013</year>
+      <year>1998</year><year>2016</year>
       <holder>Ericsson AB. All Rights Reserved.</holder>
     </copyright>
     <legalnotice>
@@ -29,16 +29,16 @@
     <rev></rev>
   </header>
   <module>int</module>
-  <modulesummary>Interpreter Interface</modulesummary>
+  <modulesummary>Interpreter Interface.</modulesummary>
   <description>
     <p>The Erlang interpreter provides mechanisms for breakpoints and
-      stepwise execution of code. It is mainly intended to be used by
-      the <em>Debugger</em>, see Debugger User's Guide and
-      <c>debugger(3)</c>.</p>
+      stepwise execution of code. It is primarily intended to be used by
+      Debugger, see the User's Guide and
+      <seealso marker="debugger"><c>debugger(3)</c></seealso>.</p>
     
-    <p>From the shell, it is possible to:</p>
-    <list>
-      <item>Specify which modules should be interpreted.</item>
+    <p>The following can be done from the shell:</p>
+    <list type="bulleted">
+      <item>Specify the modules to be interpreted.</item>
       <item>Specify breakpoints.</item>
       <item>Monitor the current status of all processes executing code
 	in interpreted modules, also processes at other Erlang nodes.
@@ -48,45 +48,48 @@
     <p>By <em>attaching to</em> a process executing interpreted code, it
       is possible to examine variable bindings and order stepwise
       execution. This is done by sending and receiving information
-      to/from the process via a third process, called the meta process.
-      It is possible to implement your own attached process. See
+      to/from the process through a third process, called the meta
+      process. You can implement your own attached process. See
       <c>int.erl</c> for available functions and <c>dbg_wx_trace.erl</c>
       for possible messages.</p>
 
-    <p>The interpreter depends on the Kernel, STDLIB and GS
-      applications, which means modules belonging to any of these
-      applications are not allowed to be interpreted as it could lead
+    <p>The interpreter depends on the Kernel, STDLIB, and
+      GS applications. This means that modules belonging to any of
+      these applications are not allowed to be interpreted, as it could lead
       to a deadlock or emulator crash. This also applies to modules
-      belonging to the Debugger application itself.</p>
+      belonging to the Debugger application.</p>
   </description>
 
   <section>
+    <marker id="int_breakpoints"/>
     <title>Breakpoints</title>
 
     <p>Breakpoints are specified on a line basis. When a process
       executing code in an interpreted module reaches a breakpoint, it
-      will stop. This means that that a breakpoint must be set at an
-      executable line, that is, a line of code containing an executable
+      stops. This means that a breakpoint must be set at an
+      executable line, that is, a code line containing an executable
       expression.</p>
 
-    <p>A breakpoint have a status, a trigger action and may have a
-      condition associated with it. The status is either <em>active</em>
-      or <em>inactive</em>. An inactive breakpoint is ignored. When a
-      breakpoint is reached, the trigger action specifies if
-      the breakpoint should continue to be active (<em>enable</em>), if
-      it should become inactive (<em>disable</em>), or if it should be
-      removed (<em>delete</em>). A condition is a tuple
-      <c>{Module,Name}</c>. When the breakpoint is reached,
-      <c>Module:Name(Bindings)</c> is called. If this evaluates to
-      <c>true</c>, execution will stop. If this evaluates to
-      <c>false</c>, the breakpoint is ignored. <c>Bindings</c> contains
-      the current variable bindings, use <c>get_binding</c> to retrieve
-      the value for a given variable.</p>
+    <p>A breakpoint has the following:</p>
+    <list type="bulleted">
+      <item>A status, which is <em>active</em> or <em>inactive</em>. An
+        inactive breakpoint is ignored.</item>
+      <item>A trigger action. When a breakpoint is reached, the trigger
+        action specifies if the breakpoint is to continue as active
+        (<em>enable</em>), or to become inactive (<em>disable</em>), or
+        to be removed (<em>delete</em>).</item>
+      <item>Optionally an associated condition. A condition is a tuple
+        <c>{Module,Name}</c>. When the breakpoint is reached,
+        <c>Module:Name(Bindings)</c> is called. If it evaluates to
+        <c>true</c>, execution stops. If it evaluates to <c>false</c>,
+        the breakpoint is ignored. <c>Bindings</c> contains the current
+        variable bindings. To retrieve the value for a specified variable,
+        use <c>get_binding</c>.</item>
+    </list>
 
     <p>By default, a breakpoint is active, has trigger action
-      <c>enable</c> and has no condition associated with it. For more
-      detailed information about breakpoints, refer to Debugger User's
-      Guide.</p>
+      <c>enable</c>, and has no associated condition. For details
+      about breakpoints, see the User's Guide.</p>
   </section>
 
   <funcs>
@@ -95,7 +98,7 @@
       <name>i(AbsModules) -> ok</name>
       <name>ni(AbsModule) -> {module,Module} | error</name>
       <name>ni(AbsModules) -> ok</name>
-      <fsummary>Interpret a module</fsummary>
+      <fsummary>Interpret a module.</fsummary>
       <type>
 	<v>AbsModules = [AbsModule]</v>
 	<v>AbsModule = Module | File | [Module | File]</v>
@@ -107,41 +110,43 @@
 	  the module only at the current node. <c>ni/1</c> interprets
 	  the module at all known nodes.</p>
 
-	<p>A module may be given by its module name (atom) or by its
-	  file name. If given by its module name, the object code
+	<p>A module can be specified by its module name (atom) or
+	  filename.</p>
+
+	<p>If specified by its module name, the object code
 	  <c>Module.beam</c> is searched for in the current path.
 	  The source code <c>Module.erl</c> is searched for first in
-	  the same directory as the object code, then in a <c>src</c>
+	  the same directory as the object code, then in an <c>src</c>
 	  directory next to it.</p>
 
-	<p>If given by its file name, the file name may include a path
-	  and the <c>.erl</c> extension may be omitted. The object code
+	<p>If specified by its filename, the filename can include a path
+	  and the <c>.erl</c> extension can  be omitted. The object code
 	  <c>Module.beam</c> is searched for first in the same directory
 	  as the source code, then in an <c>ebin</c> directory next to
 	  it, and then in the current path.</p>
 
 	<note>
-	  <p>The interpreter needs both the source code and the object
-	    code, and the object code <em>must</em> include debug
-	    information. That is, only modules compiled with the option
+	  <p>The interpreter requires both the source code and the object
+	    code. The object code <em>must</em> include debug
+	    information, that is, only modules compiled with option
 	    <c>debug_info</c> set can be interpreted.</p>
 	</note>
 
 	<p>The functions returns <c>{module,Module}</c> if the module
-	  was interpreted, or <c>error</c> if it was not.</p>
+	  was interpreted, otherwise <c>error</c> is returned.</p>
 
-	<p>The argument may also be a list of modules/file names, in
+	<p>The argument can also be a list of modules or filenames, in
 	  which case the function tries to interpret each module as
-	  specified above. The function then always returns <c>ok</c>,
-	  but prints some information to stdout if a module could not be
-	  interpreted.</p>
+	  specified earlier. The function then always returns <c>ok</c>,
+	  but prints some information to <c>stdout</c> if a module
+	  cannot be interpreted.</p>
       </desc>
     </func>
 	
     <func>
       <name>n(AbsModule) -> ok</name>
       <name>nn(AbsModule) -> ok</name>
-      <fsummary>Stop interpreting a module</fsummary>
+      <fsummary>Stop interpreting a module.</fsummary>
       <type>
 	<v>AbsModule = Module | File | [Module | File]</v>
 	<v>&nbsp;Module = atom()</v>
@@ -152,14 +157,14 @@
 	  interpreting the module only at the current node. <c>nn/1</c>
 	  stops interpreting the module at all known nodes.</p>
 
-	<p>As for <c>i/1</c> and <c>ni/1</c>, a module may be given by
-	  either its module name or its file name.</p>
+	<p>As for <c>i/1</c> and <c>ni/1</c>, a module can be specified by
+	  its module name or filename.</p>
       </desc>
     </func>
 
     <func>
       <name>interpreted() -> [Module]</name>
-      <fsummary>Get all interpreted modules</fsummary>
+      <fsummary>Get all interpreted modules.</fsummary>
       <type>
 	<v>Module = atom()</v>
       </type>
@@ -170,20 +175,20 @@
 
     <func>
       <name>file(Module) -> File | {error,not_loaded}</name>
-      <fsummary>Get the file name for an interpreted module</fsummary>
+      <fsummary>Get the filename for an interpreted module.</fsummary>
       <type>
 	<v>Module = atom()</v>
 	<v>File = string()</v>
       </type>
       <desc>
-	<p>Returns the source code file name <c>File</c> for an
+	<p>Returns the source code filename <c>File</c> for an
 	  interpreted module <c>Module</c>.</p>
       </desc>
     </func>
 
     <func>
       <name>interpretable(AbsModule) -> true | {error,Reason}</name>
-      <fsummary>Check if a module is possible to interpret</fsummary>
+      <fsummary>Check if a module can be interpreted.</fsummary>
       <type>
 	<v>AbsModule = Module | File</v>
 	<v>&nbsp;Module = atom()</v>
@@ -193,45 +198,59 @@
 	<v>&nbsp;App = atom()</v>
       </type>
       <desc>
-	<p>Checks if a module is possible to interpret. The module can
-	  be given by its module name <c>Module</c> or its source file
-	  name <c>File</c>. If given by a module name, the module is
-	  searched for in the code path.</p>
-
-	<p>The function returns <c>true</c> if both source code and
-	  object code for the module is found, the module has been
-	  compiled with the option <c>debug_info</c> set and does not
-	  belong to any of the applications Kernel, STDLIB, GS or
-	  Debugger itself.</p>
-
-	<p>The function returns <c>{error,Reason}</c> if the module for
-	  some reason is not possible to interpret.</p>
-	
-	<p><c>Reason</c> is <c>no_src</c> if no source code is found or
-	  <c>no_beam</c> if no object code is found. It is assumed that
-	  the source- and object code are located either in the same
-	  directory, or in <c>src</c> and <c>ebin</c> directories next
-	  to each other.</p>
-
-	<p><c>Reason</c> is <c>no_debug_info</c> if the module has not
-	  been compiled with the option <c>debug_info</c> set.</p>
-
-	<p><c>Reason</c> is <c>badarg</c> if <c>AbsModule</c> is not
-	  found. This could be because the specified file does not
-	  exist, or because <c>code:which/1</c> does not return a
-	  beam file name, which is the case not only for non-existing
-	  modules but also for modules which are preloaded or cover
-	  compiled.</p>
-
-	<p><c>Reason</c> is <c>{app,App}</c> where <c>App</c> is
-	  <c>kernel</c>, <c>stdlib</c>, <c>gs</c> or <c>debugger</c> if
-	  <c>AbsModule</c> belongs to one of these applications.</p>
-
-	<p>Note that the function can return <c>true</c> for a module
-	  which in fact is not interpretable in the case where
+	<p>Checks if a module can be interpreted. The module can be
+	  specified by its module name <c>Module</c> or its source
+	  filename <c>File</c>. If specified by a module name, the module
+	  is searched for in the code path.</p>
+
+	<p>The function returns <c>true</c> if all of the following
+          apply:</p>
+	<list type="bulleted">
+          <item>Both source code and object code for the module is
+            found.</item>
+          <item>The module has been compiled with option <c>debug_info</c>
+            set.</item>
+          <item>The module does not belong to any of the applications
+            Kernel, STDLIB, GS, or Debugger.</item>
+	</list>
+
+	<p>The function returns <c>{error,Reason}</c> if the module cannot
+	  be interpreted. <c>Reason</c> can have the following values:</p>
+	<taglist>
+	  <tag><c>no_src</c></tag>
+	  <item><p>No source code is found.
+	    It is assumed that the source code and object code are located
+	    either in the same directory, or in <c>src</c> and <c>ebin</c>
+	    directories next to each other.</p></item>
+
+	  <tag><c>no_beam</c></tag>
+	  <item><p>No object code is found.
+	    It is assumed that the source code and object code are located
+	    either in the same directory, or in <c>src</c> and <c>ebin</c>
+	    directories next to each other.</p></item>
+
+	  <tag><c>no_debug_info</c></tag>
+	  <item><p>The module has not been compiled with option
+	    <c>debug_info</c> set.</p></item>
+
+	  <tag><c>badarg</c></tag>
+	  <item><p><c>AbsModule</c> is not found. This could be because
+	    the specified file does not exist, or because
+	    <c>code:which/1</c> does not return a BEAM filename,
+	    which is the case not only for non-existing modules but also
+	    for modules that are preloaded or cover-compiled.</p></item>
+
+	  <tag><c>{app,App}</c></tag>
+	  <item><p><c>App</c> is <c>kernel</c>, <c>stdlib</c>, <c>gs</c>,
+	  or <c>debugger</c> if <c>AbsModule</c> belongs to one of these
+	  applications.</p></item>
+	</taglist>
+
+	<p>Notice that the function can return <c>true</c> for a module
+	  that in fact is not interpretable in the case where
 	  the module is marked as sticky or resides in a directory
-	  marked as sticky, as this is not discovered until
-	  the interpreter actually tries to load the module.</p>
+	  marked as sticky. The reason is that this is not discovered
+	  until the interpreter tries to load the module.</p>
       </desc>
     </func>
 
@@ -239,7 +258,7 @@
       <name>auto_attach() -> false | {Flags,Function}</name>
       <name>auto_attach(false)</name>
       <name>auto_attach(Flags, Function)</name>
-      <fsummary>Get/set when and how to attach to a process</fsummary>
+      <fsummary>Get and set when and how to attach to a process.</fsummary>
       <type>
 	<v>Flags = [init | break | exit]</v>
 	<v>Function = {Module,Name,Args}</v>
@@ -247,24 +266,24 @@
 	<v>&nbsp;Args = [term()]</v>
       </type>
       <desc>
-	<p>Gets and sets when and how to automatically attach to a
+	<p>Gets and sets when and how to attach automatically to a
 	  process executing code in interpreted modules. <c>false</c>
-	  means never automatically attach, this is the default.
+	  means never attach automatically, this is the default.
 	  Otherwise automatic attach is defined by a list of flags and
-	  a function. The following flags may be specified:</p>
-	<list>
-	  <item><c>init</c> - attach when a process for the very first
+	  a function. The following flags can be specified:</p>
+	<list type="bulleted">
+	  <item><c>init</c> - Attach when a process for the first
 	    time calls an interpreted function.</item>
-	  <item><c>break</c> - attach whenever a process reaches a
+	  <item><c>break</c> - Attach whenever a process reaches a
 	    breakpoint.</item>
-	  <item><c>exit</c> - attach when a process terminates.</item>
+	  <item><c>exit</c> - Attach when a process terminates.</item>
 	</list>
 
 	<p>When the specified event occurs, the function <c>Function</c>
-	  will be called as:</p>
+	  is called as:</p>
 	<pre>
-spawn(Module, Name, [Pid | Args])
-	</pre>
+spawn(Module, Name, [Pid | Args])</pre>
+
 	<p><c>Pid</c> is the pid of the process executing interpreted
 	  code.</p>
       </desc>
@@ -273,7 +292,7 @@ spawn(Module, Name, [Pid | Args])
     <func>
       <name>stack_trace() -> Flag</name>
       <name>stack_trace(Flag)</name>
-      <fsummary>Get/set if and how to save call frames</fsummary>
+      <fsummary>Get and set if and how to save call frames.</fsummary>
       <type>
 	<v>Flag = all | no_tail | false</v>
       </type>
@@ -281,25 +300,30 @@ spawn(Module, Name, [Pid | Args])
 	<p>Gets and sets how to save call frames in the stack. Saving
 	  call frames makes it possible to inspect the call chain of a
 	  process, and is also used to emulate the stack trace if an
-	  error (an exception of class error) occurs.</p>
-	<list>
-	  <item><c>all</c> - save information about all current calls,
-	    that is, function calls that have not yet returned a value.
-	    </item>
-	  <item><c>no_tail</c> - save information about current calls,
+	  error (an exception of class error) occurs. The following
+	  flags can be specified:</p>
+	<taglist>
+	  <tag><c>all</c></tag>
+	  <item><p>Save information about all current calls,
+	    that is, function calls that have not yet returned a value.</p>
+	  </item>
+
+	  <tag><c>no_tail</c></tag>
+	  <item><p>Save information about current calls,
 	    but discard previous information when a tail recursive call
-	    is made. This option consumes less memory and may be
+	    is made. This option consumes less memory and can be
 	    necessary to use for processes with long lifetimes and many
-	    tail recursive calls. This is the default.</item>
-	  <item><c>false</c> - do not save any information about current
-	    calls.</item>
-	</list>
+	    tail recursive calls. This is the default.</p></item>
+
+	  <tag><c>false</c></tag>
+	  <item><p>Save no information about currentcalls.</p></item>
+	</taglist>
       </desc>
     </func>
 
     <func>
       <name>break(Module, Line) -> ok | {error,break_exists}</name>
-      <fsummary>Create a breakpoint</fsummary>
+      <fsummary>Create a breakpoint.</fsummary>
       <type>
 	<v>Module = atom()</v>
 	<v>Line = int()</v>
@@ -311,86 +335,80 @@ spawn(Module, Name, [Pid | Args])
 
     <func>
       <name>delete_break(Module, Line) -> ok</name>
-      <fsummary>Delete a breakpoint</fsummary>
+      <fsummary>Delete a breakpoint.</fsummary>
       <type>
 	<v>Module = atom()</v>
 	<v>Line = int()</v>
       </type>
       <desc>
-	<p>Deletes the breakpoint located at <c>Line</c> in
-	  <c>Module</c>.</p>
+	<p>Deletes the breakpoint at <c>Line</c> in <c>Module</c>.</p>
       </desc>
     </func>
 
     <func>
       <name>break_in(Module, Name, Arity) -> ok
 	| {error,function_not_found}</name>
-      <fsummary>Create breakpoints in the specified function</fsummary>
+      <fsummary>Create breakpoints in the specified function.</fsummary>
       <type>
 	<v>Module = Name = atom()</v>
 	<v>Arity = int()</v>
       </type>
       <desc>
 	<p>Creates a breakpoint at the first line of every clause of 
-	  the <c>Module:Name/Arity</c> function.</p>
+	  function <c>Module:Name/Arity</c>.</p>
       </desc>
     </func>
 
     <func>
       <name>del_break_in(Module, Name, Arity) -> ok
 	| {error,function_not_found}</name>
-      <fsummary>Delete breakpoints from the specified function
-      </fsummary>
+      <fsummary>Delete breakpoints from the specified function.</fsummary>
       <type>
 	<v>Module = Name = atom()</v>
 	<v>Arity = int()</v>
       </type>
       <desc>
 	<p>Deletes the breakpoints at the first line of every clause of 
-	  the <c>Module:Name/Arity</c> function.
-	</p>
+	  function <c>Module:Name/Arity</c>.</p>
       </desc>
     </func>
 
     <func>
       <name>no_break() -> ok</name>
       <name>no_break(Module) -> ok</name>
-      <fsummary>Delete all breakpoints</fsummary>
+      <fsummary>Delete all breakpoints.</fsummary>
       <desc>
-	<p>Deletes all breakpoints, or all breakpoints in <c>Module</c>.
-	</p>
+	<p>Deletes all breakpoints, or all breakpoints in <c>Module</c>.</p>
       </desc>
     </func>
 
     <func>
       <name>disable_break(Module, Line) -> ok</name>
-      <fsummary>Make a breakpoint inactive</fsummary>
+      <fsummary>Make a breakpoint inactive.</fsummary>
       <type>
 	<v>Module = atom()</v>
 	<v>Line = int()</v>
       </type>
       <desc>
-	<p>Makes the breakpoint at <c>Line</c> in <c>Module</c>
-	  inactive.</p>
+	<p>Makes the breakpoint at <c>Line</c> in <c>Module</c> inactive.</p>
       </desc>
     </func>
 
     <func>
       <name>enable_break(Module, Line) -> ok</name>
-      <fsummary>Make a breakpoint active</fsummary>
+      <fsummary>Make a breakpoint active.</fsummary>
       <type>
 	<v>Module = atom()</v>
 	<v>Line = int()</v>
       </type>
       <desc>
-	<p>Makes the breakpoint at <c>Line</c> in <c>Module</c> active.
-	</p>
+	<p>Makes the breakpoint at <c>Line</c> in <c>Module</c> active.</p>
       </desc>
     </func>
 
     <func>
       <name>action_at_break(Module, Line, Action) -> ok</name>
-      <fsummary>Set the trigger action of a breakpoint</fsummary>
+      <fsummary>Set the trigger action of a breakpoint.</fsummary>
       <type>
 	<v>Module = atom()</v>
 	<v>Line = int()</v>
@@ -404,7 +422,7 @@ spawn(Module, Name, [Pid | Args])
 
     <func>
       <name>test_at_break(Module, Line, Function) -> ok</name>
-      <fsummary>Set the conditional test of a breakpoint</fsummary>
+      <fsummary>Set the conditional test of a breakpoint.</fsummary>
       <type>
 	<v>Module = atom()</v>
 	<v>Line = int()</v>
@@ -414,14 +432,14 @@ spawn(Module, Name, [Pid | Args])
       <desc>
 	<p>Sets the conditional test of the breakpoint at <c>Line</c> in
 	  <c>Module</c> to <c>Function</c>. The function must
-	  fulfill the requirements specified in the section
-	  <em>Breakpoints</em> above.</p>
+	  fulfill the requirements specified in section
+          <seealso marker="#int_breakpoints">Breakpoints</seealso>.</p>
       </desc>
     </func>
 
     <func>
       <name>get_binding(Var, Bindings) -> {value,Value} | unbound</name>
-      <fsummary>Retrieve a variable binding</fsummary>
+      <fsummary>Retrieve a variable binding.</fsummary>
       <type>
 	<v>Var = atom()</v>
 	<v>Bindings = term()</v>
@@ -437,7 +455,7 @@ spawn(Module, Name, [Pid | Args])
     <func>
       <name>all_breaks() -> [Break]</name>
       <name>all_breaks(Module) -> [Break]</name>
-      <fsummary>Get all breakpoints</fsummary>
+      <fsummary>Get all breakpoints.</fsummary>
       <type>
 	<v>Break = {Point,Options}</v>
 	<v>&nbsp;Point = {Module,Line}</v>
@@ -451,15 +469,14 @@ spawn(Module, Name, [Pid | Args])
 	<v>&nbsp;&nbsp;&nbsp;&nbsp;Name = atom()</v>
       </type>
       <desc>
-	<p>Gets all breakpoints, or all breakpoints in <c>Module</c>.
-	</p>
+	<p>Gets all breakpoints, or all breakpoints in <c>Module</c>.</p>
       </desc>
     </func>
 
     <func>
       <name>snapshot() -> [Snapshot]</name>
       <fsummary>Get information about all processes executing interpreted
-	code</fsummary>
+	code.</fsummary>
       <type>
 	<v>Snapshot = {Pid, Function, Status, Info}</v>
 	<v>&nbsp;Pid = pid()</v>
@@ -475,26 +492,27 @@ spawn(Module, Name, [Pid | Args])
       <desc>
 	<p>Gets information about all processes executing interpreted code.
 	</p>
-	<list>
-	  <item><c>Pid</c> - process identifier.</item>
-	  <item><c>Function</c> - first interpreted function called by
+	<list type="bulleted">
+	  <item><c>Pid</c> - Process identifier.</item>
+	  <item><c>Function</c> - First interpreted function called by
 	    the process.</item>
-	  <item><c>Status</c> - current status of the process.</item>
-	  <item><c>Info</c> - additional information.</item>
+	  <item><c>Status</c> - Current status of the process.</item>
+	  <item><c>Info</c> - More information.</item>
 	</list>
-	<p><c>Status</c> is one of:</p>
-	<list>
-	  <item><c>idle</c> - the process is no longer executing
+
+	<p><c>Status</c> is one of the following:</p>
+	<list type="bulleted">
+	  <item><c>idle</c> - The process is no longer executing
 	    interpreted code. <c>Info={}</c>.</item>
-	  <item><c>running</c> - the process is running. <c>Info={}</c>.
+	  <item><c>running</c> - The process is running. <c>Info={}</c>.
 	  </item>
-	  <item><c>waiting</c> - the process is waiting at a
+	  <item><c>waiting</c> - The process is waiting at a
 	    <c>receive</c>. <c>Info={}</c>.</item>
-	  <item><c>break</c> - process execution has been stopped,
+	  <item><c>break</c> - Process execution is stopped,
 	    normally at a breakpoint. <c>Info={Module,Line}</c>.</item>
-	  <item><c>exit</c> - the process has terminated.
+	  <item><c>exit</c> - The process is terminated.
 	    <c>Info=ExitReason</c>.</item>
-	  <item><c>no_conn</c> - the connection is down to the node
+	  <item><c>no_conn</c> - The connection is down to the node
 	    where the process is running. <c>Info={}</c>.</item>
 	</list>
       </desc>
@@ -503,7 +521,7 @@ spawn(Module, Name, [Pid | Args])
     <func>
       <name>clear() -> ok</name>
       <fsummary>Clear information about processes executing interpreted
-	code</fsummary>
+	code.</fsummary>
       <desc>
 	<p>Clears information about processes executing interpreted code
 	  by removing all information about terminated processes.</p>
@@ -513,13 +531,13 @@ spawn(Module, Name, [Pid | Args])
     <func>
       <name>continue(Pid) -> ok | {error,not_interpreted}</name>
       <name>continue(X,Y,Z) -> ok | {error,not_interpreted}</name>
-      <fsummary>Resume process execution</fsummary>
+      <fsummary>Resume process execution.</fsummary>
       <type>
 	<v>Pid = pid()</v>
 	<v>X = Y = Z = int()</v>
       </type>
       <desc>
-	<p>Resume process execution for <c>Pid</c>, or for
+	<p>Resumes process execution for <c>Pid</c> or
 	  <c>c:pid(X,Y,Z)</c>.</p>
       </desc>
     </func>
diff --git a/lib/debugger/doc/src/introduction.xml b/lib/debugger/doc/src/introduction.xml
new file mode 100644
index 0000000000..9f5f279bb0
--- /dev/null
+++ b/lib/debugger/doc/src/introduction.xml
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE chapter SYSTEM "chapter.dtd">
+
+<chapter>
+<header>
+    <copyright>
+      <year>1997</year><year>2013</year>
+      <holder>Ericsson AB. All Rights Reserved.</holder>
+    </copyright>
+    <legalnotice>
+      Licensed under the Apache License, Version 2.0 (the "License");
+      you may not use this file except in compliance with the License.
+      You may obtain a copy of the License at
+ 
+          http://www.apache.org/licenses/LICENSE-2.0
+
+      Unless required by applicable law or agreed to in writing, software
+      distributed under the License is distributed on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+      See the License for the specific language governing permissions and
+      limitations under the License.
+    
+    </legalnotice>
+
+    <title>Introduction</title>
+    <prepared></prepared>
+    <docno></docno>
+    <date></date>
+    <rev></rev>
+    <file>introduction.xml</file>
+  </header>
+
+  <section>
+    <title>Scope</title>
+    <p>Debugger is a graphical user interface for the Erlang
+      interpreter, which can be used for debugging and testing of
+      Erlang programs. For example, breakpoints can be set, code can be
+      single-stepped and variable values can be displayed and changed.
+    </p>
+
+    <p>The Erlang interpreter can also be accessed through the interface
+      module <seealso marker="int"><c>int(3)</c></seealso>.
+    </p>
+
+    <warning>
+      <p>Debugger might at some point
+      start tracing on the processes that execute the interpreted
+      code. This means that a conflict occurs if tracing by other
+      means is started on any of these processes.</p>
+    </warning>
+  </section>
+
+  <section>
+    <title>Prerequisites</title>
+    <p>It is assumed that the reader is familiar with the Erlang
+      programming language.</p>
+    <p>Modules to be debugged must include debug information,
+      for example, <c>erlc +debug_info MODULE.erl</c>.</p>
+  </section>
+
+</chapter>
+
+
diff --git a/lib/debugger/doc/src/part.xml b/lib/debugger/doc/src/part.xml
index 7515c0ad5b..ce1edbd978 100644
--- a/lib/debugger/doc/src/part.xml
+++ b/lib/debugger/doc/src/part.xml
@@ -4,7 +4,7 @@
 <part xmlns:xi="http://www.w3.org/2001/XInclude">
   <header>
     <copyright>
-      <year>1997</year><year>2013</year>
+      <year>1997</year><year>2016</year>
       <holder>Ericsson AB. All Rights Reserved.</holder>
     </copyright>
     <legalnotice>
@@ -27,14 +27,10 @@
     <docno></docno>
     <date>1998-05-12</date>
     <rev>B</rev>
-    <file>part.sgml</file>
+    <file>part.xml</file>
   </header>
-  <description>
-    <p><em>Debugger</em> is a graphical tool which can be used for
-      debugging and testing of Erlang programs. For example, breakpoints
-      can be set, code can be single stepped and variable values can be
-      displayed and changed.</p>
-  </description>
+  <description></description>
+  <xi:include href="introduction.xml"/>
   <xi:include href="debugger_chapter.xml"/>
 </part>
 
diff --git a/lib/debugger/doc/src/ref_man.xml b/lib/debugger/doc/src/ref_man.xml
index 6df9e90c2c..c44f07f912 100644
--- a/lib/debugger/doc/src/ref_man.xml
+++ b/lib/debugger/doc/src/ref_man.xml
@@ -28,12 +28,7 @@
     <date></date>
     <rev></rev>
   </header>
-  <description>
-    <p><em>Debugger</em> is a graphical tool which can be used for
-      debugging and testing of Erlang programs. For example, breakpoints
-      can be set, code can be single stepped and variable values can be
-      displayed and changed.</p>
-  </description>
+  <description></description>
   <xi:include href="debugger.xml"/>
   <xi:include href="i.xml"/>
   <xi:include href="int.xml"/>