X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fghci.xml;h=b1e36ec8403f63bcddf218e3368537ea028e3ba6;hb=1a38a09d1077b507a0a4e1ebba8e1b51bd5fede9;hp=e034021c3857fdd953090c8a0f2ee696e2fef1df;hpb=2df369da6d961f278b231aac6d21fdd25dafaf31;p=ghc-hetmet.git

diff --git a/docs/users_guide/ghci.xml b/docs/users_guide/ghci.xml
index e034021..b1e36ec 100644
--- a/docs/users_guide/ghci.xml
+++ b/docs/users_guide/ghci.xml
@@ -1106,10 +1106,14 @@ right :: [a]
 
       <para>Single-stepping is a great way to visualise the execution of your
         program, and it is also a useful tool for identifying the source of a
-        bug.  The concept is simple: single-stepping enables all the
-        breakpoints in the program and executes until the next breakpoint is
-        reached, at which point you can single-step again, or continue
-        normally.  For example:</para>
+        bug. GHCi offers two variants of stepping. Use 
+	<literal>:step</literal>  to enable all the
+        breakpoints in the program, and execute until the next breakpoint is
+        reached. Use <literal>:steplocal</literal> to limit the set
+	of enabled breakpoints to those in the current top level function.
+	Similarly, use <literal>:stepmodule</literal> to single step only on
+	breakpoints contained in the current module.
+	For example:</para>
 
 <screen>
 *Main> :step main
@@ -1118,10 +1122,11 @@ _result :: IO ()
 </screen>
 
       <para>The command <literal>:step
-          <replaceable>expr</replaceable></literal> begins the evaluation of
+        <replaceable>expr</replaceable></literal> begins the evaluation of
         <replaceable>expr</replaceable> in single-stepping mode.  If
         <replaceable>expr</replaceable> is ommitted, then it single-steps from
-        the current breakpoint.</para>
+        the current breakpoint. <literal>:stepover</literal> 
+        works similarly.</para>
 
       <para>The <literal>:list</literal> command is particularly useful when
         single-stepping, to see where you currently are:</para>
@@ -1330,9 +1335,13 @@ a :: a
         <literal>:trace</literal> and <literal>:history</literal> to establish
         the context.  However, <literal>head</literal> is in a library and
         we can't set a breakpoint on it directly.  For this reason, GHCi
-        provides the flag <literal>-fbreak-on-exception</literal> which causes
-        the evaluator to stop when an exception is thrown, just as it does when
-        a breakpoint is hit.  This is only really useful in conjunction with
+        provides the flags <literal>-fbreak-on-exception</literal> which causes
+        the evaluator to stop when an exception is thrown, and <literal>
+	-fbreak-on-error</literal>, which works similarly but stops only on 
+	uncaught exceptions. When stopping at an exception, GHCi will act 
+	just as it does when a breakpoint is hit, with the deviation that it
+	will not show you any source code location. Due to this, these 
+	commands are only really useful in conjunction with
         <literal>:trace</literal>, in order to log the steps leading up to the
         exception.  For example:</para>
 
@@ -1923,6 +1932,12 @@ Prelude> :. cmds.ghci
 	  will be printed.  If <replaceable>name</replaceable> has
 	  been loaded from a source file, then GHCi will also display
 	  the location of its definition in the source.</para>
+	  <para>For types and classes, GHCi also summarises instances that
+	  mention them.  To avoid showing irrelevant information, an instance
+	  is shown only if (a) its head mentions <replaceable>name</replaceable>, 
+	  and (b) all the other things mentioned in the instance
+	  are in scope (either qualified or otherwise) as a result of 
+	  a <literal>:load</literal> or <literal>:module</literal> commands. </para>
 	</listitem>
       </varlistentry>
 
@@ -2424,9 +2439,10 @@ Prelude> :set -fno-glasgow-exts
     <indexterm><primary>startup</primary><secondary>files, GHCi</secondary>
     </indexterm>
 
-    <para>When it starts, GHCi always reads and executes commands from
-    <filename>$HOME/.ghci</filename>, followed by
-    <filename>./.ghci</filename>.</para>
+    <para>When it starts, unless the <literal>-ignore-dot-ghci</literal>
+    flag is given, GHCi reads and executes commands from
+    <filename>./.ghci</filename>, followed by
+    <filename>$HOME/.ghci</filename>.</para>
 
     <para>The <filename>.ghci</filename> in your home directory is
     most useful for turning on favourite options (eg. <literal>:set
@@ -2435,7 +2451,7 @@ Prelude> :set -fno-glasgow-exts
     project is a useful way to set certain project-wide options so you
     don't have to type them everytime you start GHCi: eg. if your
     project uses GHC extensions and CPP, and has source files in three
-    subdirectories A B and C, you might put the following lines in
+    subdirectories A, B and C, you might put the following lines in
     <filename>.ghci</filename>:</para>
 
 <screen>
@@ -2583,7 +2599,19 @@ Prelude> :set -fno-glasgow-exts
 	<term>I can't use Control-C to interrupt computations in
           GHCi on Windows.</term>
         <listitem>
-          <para>See <xref linkend="ghci-windows"/></para>
+          <para>See <xref linkend="ghci-windows"/>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+	<term>The default buffering mode is different in GHCi to GHC.</term>
+        <listitem>
+          <para>
+            In GHC, the stdout handle is line-buffered by default.
+            However, in GHCi we turn off the buffering on stdout,
+            because this is normally what you want in an interpreter:
+            output appears as it is generated.
+          </para>
         </listitem>
       </varlistentry>
     </variablelist>