diff --git a/Command-line.md b/Command-line.md
index d41e13e..2feeebc 100644
--- a/Command-line.md
+++ b/Command-line.md
@@ -5,6 +5,18 @@ Note that options are described according to the following pattern:
 
 *<description>*
 
+<a href="#usage">    <pre>-h, -?, --help</pre></a>
+<a href="#nothrow">  <pre>-n, --nothrow</pre></a>
+<a href="#test">     <pre>-t, --test</pre></a>
+<a href="#reporter"> <pre>-r, --reporter</pre></a>
+<a href="#break">    <pre>-b, --break</pre></a>
+<a href="#success">  <pre>-s, --success</pre></a>
+<a href="#abort">    <pre>-a, --abort</pre></a>
+<a href="#list">     <pre>-l, --list</pre></a>
+<a href="#output">   <pre>-o, --out</pre></a>
+<a href="#name">     <pre>-n, --name</pre></a>
+
+<a name="usage" />
 ## Usage
 <pre>
 -h, -?, --help
@@ -12,6 +24,7 @@ Note that options are described according to the following pattern:
 
 Prints the command line arguments to stdout
 
+<a name="test" />
 ## Specifying which tests to run
 
 <pre>
@@ -27,6 +40,7 @@ Alternatively use -t or --test to specify which tests to run. This option takes
 -t example/group/*
 </pre>
 
+<a name="reporter" />
 ## Choosing a reporter to use
 
 <pre>
@@ -44,6 +58,7 @@ The bundled reporters are:
 
 The JUnit reporter is an xml format that follows the structure of the JUnit XML Report ANT task, as consumed by a number of third-party tools, including Continuous Integration servers such as Hudson. If not otherwise needed, the standard XML reporter is preferred as this is a streaming reporter, whereas the Junit reporter needs to hold all its results until the end so it can write the overall results into attributes of the root node.
 
+<a name="break" />
 ## Breaking into the debugger
 <pre>
 -b, --break
@@ -52,6 +67,7 @@ The JUnit reporter is an xml format that follows the structure of the JUnit XML
 In some IDEs (currently XCode and Visual Studio) it is possible for CATCH to break into the debugger on a test failure. This can be very helpful during debug sessions - especially when there is more than one path through a particular test.
 In addition to the command line option, ensure you have built your code with the DEBUG preprocessor symbol
 
+<a name="success" />
 ## Showing results for successful tests
 <pre>
 -s, --success
@@ -60,6 +76,7 @@ In addition to the command line option, ensure you have built your code with the
 Usually you only want to see reporting for failed tests. Sometimes it's useful to see *all* the output (especially when you don't trust that that test you just added worked first time!).
 To see successul, as well as failing, test results just pass this option.
 
+<a name="abort" />
 ## Aborting after a certain number of failures
 <pre>
 -a, --abort [&lt;failure threshold>]
@@ -70,6 +87,7 @@ If a CHECK assertion fails even the current test case is not aborted.
 
 Sometimes this results in a flood of failure messages and you'd rather just see the first few. Specifying -a or --abort on its own will abort the whole test run on the first failed assertion of any kind. Following it with a number causes it to abort after that number of assertion failures.
 
+<a name="list" />
 ## Listing available tests or reporters
 <pre>
 -l, --list [tests | reporters] [xml]
@@ -87,6 +105,7 @@ Examples:
 -l xml
 </pre>
 
+<a name="output" />
 ## Sending output to a file or stream
 <pre>
 -o, --out &lt;filename> | &lt;%streamname>
@@ -100,6 +119,7 @@ Recognised stream names are:
 * %stderr
 * %debug (The IDE's debug output window - currently only Windows' OutputDebugString is supported).
 
+<a name="name" />
 ## Naming a test run
 <pre>
 -n, --name &lt;name for test run>
@@ -113,7 +133,7 @@ Examples:
 -n "tests of the widget component"
 </pre>
 
-
+<a name="nothrow" />
 ## Eliding assertions expected to throw
 <pre>
 -nt, --nothrow