Markdown link migration part 2 (#20371)

doc/docs.md

@@ -1,38 +1,38 @@
 The documentation consists of several documents:
 
-- | `Tutorial (part I) <tut1.html>`_
+- | [Tutorial (part I)](tut1.html)
   | The Nim tutorial part one deals with the basics.
 
-- | `Tutorial (part II) <tut2.html>`_
+- | [Tutorial (part II)](tut2.html)
   | The Nim tutorial part two deals with the advanced language constructs.
 
-- | `Tutorial (part III) <tut3.html>`_
+- | [Tutorial (part III)](tut3.html)
   | The Nim tutorial part three about Nim's macro system.
 
-- | `Language Manual <manual.html>`_
+- | [Language Manual](manual.html)
   | The Nim manual is a draft that will evolve into a proper specification.
 
-- | `Library documentation <lib.html>`_
+- | [Library documentation](lib.html)
   | This document describes Nim's standard library.
 
-- | `Compiler user guide <nimc.html>`_
+- | [Compiler user guide](nimc.html)
   | The user guide lists command line arguments, special features of the
     compiler, etc.
 
-- | `Tools documentation <tools.html>`_
+- | [Tools documentation](tools.html)
   | Description of some tools that come with the standard distribution.
 
-- | `Memory management <mm.html>`_
+- | [Memory management](mm.html)
   | Additional documentation about Nim's memory management strategies
   | and how to operate them in a realtime setting.
 
-- | `Source code filters <filters.html>`_
+- | [Source code filters](filters.html)
   | The Nim compiler supports source code filters as a simple yet powerful
     builtin templating system.
 
-- | `Internal documentation <intern.html>`_
+- | [Internal documentation](intern.html)
   | The internal documentation describes how the compiler is implemented. Read
     this if you want to hack the compiler.
 
-- | `Index <theindex.html>`_
+- | [Index](theindex.html)
   | The generated index. **Index + (Ctrl+F) == Joy**

doc/docstyle.md

@@ -4,7 +4,7 @@ Documentation Style
 General Guidelines
 ------------------
 
-* See also `nep1<https://nim-lang.github.io/Nim/nep1.html>`_ which should probably be merged here.
+* See also [nep1](nep1.html) which should probably be merged here.
 * Authors should document anything that is exported; documentation for private
   procs can be useful too (visible via `nim doc --docInternal foo.nim`:cmd:).
 * Within documentation, a period (`.`) should follow each sentence (or sentence fragment) in a comment block.

doc/drnim.md

@@ -14,7 +14,7 @@ Introduction
 ============
 
 This document describes the usage of the *DrNim* tool. DrNim combines
-the Nim frontend with the `Z3 <https://github.com/Z3Prover/z3>`_ proof
+the Nim frontend with the [Z3](https://github.com/Z3Prover/z3) proof
 engine, in order to allow verify/validate software written in Nim.
 DrNim's command-line options are the same as the Nim compiler's.
 

doc/idetools.md

@@ -12,19 +12,19 @@
 
 > "yes, I'm the creator" -- Araq, 2013-07-26 19:28:32.
 
-Note: this is mostly outdated, see instead `nimsuggest <nimsuggest.html>`_
+Note: this is mostly outdated, see instead [nimsuggest](nimsuggest.html)
 
 Nim differs from many other compilers in that it is really fast,
 and being so fast makes it suited to provide external queries for
 text editors about the source code being written. Through the
-`idetools` command of `the compiler <nimc.html>`_, any IDE
+`idetools` command of [the compiler](nimc.html), any IDE
 can query a `.nim` source file and obtain useful information like
 definition of symbols or suggestions for completion.
 
 This document will guide you through the available options. If you
 want to look at practical examples of idetools support you can look
-at the test files found in the `Test suite`_ or `various editor
-integrations <https://github.com/Araq/Nim/wiki/Editor-Support>`_
+at the test files found in the [Test suite] or [various editor
+integrations](https://github.com/Araq/Nim/wiki/Editor-Support)
 already available.
 
 
@@ -124,8 +124,8 @@ to the case insensitiveness of the language (plus underscores as
 separators!).
 
 The typical usage scenario for this option is to call it after the
-user has typed the dot character for `the object oriented call
-syntax <tut2.html#object-oriented-programming-method-call-syntax>`_.
+user has typed the dot character for [the object oriented call
+syntax](tut2.html#object-oriented-programming-method-call-syntax).
 Idetools will try to return the suggestions sorted first by scope
 (from innermost to outermost) and then by item name.
 
@@ -196,7 +196,7 @@ of text it thinks necessary plus an empty line to indicate the end
 of the answer.
 
 You can find examples of client/server communication in the idetools
-tests found in the `Test suite`_.
+tests found in the [Test suite].
 
 
 Parsing idetools output
@@ -367,8 +367,8 @@ defined, since at that point in the file the parser hasn't processed
 the full line yet. The signature will be returned complete in
 posterior instances of the method.
 
-Methods imply `dynamic dispatch
-<tut2.html#object-oriented-programming-dynamic-dispatch>`_ and
+Methods imply [dynamic dispatch](
+tut2.html#object-oriented-programming-dynamic-dispatch) and
 idetools performs a static analysis on the code. For this reason
 idetools may not return the definition of the correct method you
 are querying because it may be impossible to know until the code
@@ -590,7 +590,7 @@ All the `tests/caas/*.txt` files encode a session with the compiler:
   modes, you can prefix a line with the mode and the line will be
   processed only in that mode.
 
-* The rest of the line is treated as a `regular expression <re.html>`_,
+* The rest of the line is treated as a [regular expression](re.html),
   so be careful escaping metacharacters like parenthesis.
 
 Before the line is processed as a regular expression, some basic

doc/intern.md

@@ -64,7 +64,7 @@ And for a debug version compatible with GDB:
 
 The `koch`:cmd: program is Nim's maintenance script. It is a replacement for
 make and shell scripting with the advantage that it is much more portable.
-More information about its options can be found in the `koch <koch.html>`_
+More information about its options can be found in the [koch](koch.html)
 documentation.
 
 
@@ -105,7 +105,7 @@ current commit:
 
 You can also bisect using custom options to build the compiler, for example if
 you don't need a debug version of the compiler (which runs slower), you can replace
-`./koch temp`:cmd: by explicit compilation command, see `Bootstrapping the compiler`_.
+`./koch temp`:cmd: by explicit compilation command, see [Bootstrapping the compiler].
 
 
 Building an instrumented compiler
@@ -269,7 +269,7 @@ Native debugging
 
 Stepping through the compiler with a native debugger is a very powerful tool to
 both learn and debug it. However, there is still the need to constrain when
-breakpoints are triggered. The same methods as in `Debug logging`_ can be applied
+breakpoints are triggered. The same methods as in [Debug logging] can be applied
 here when combined with calls to the debug helpers `enteringDebugSection()`:nim:
 and `exitingDebugSection()`:nim:.
 
@@ -309,7 +309,7 @@ The syntax tree consists of nodes which may have an arbitrary number of
 children. Types and symbols are represented by other nodes, because they
 may contain cycles. The AST changes its shape after semantic checking. This
 is needed to make life easier for the code generators. See the "ast" module
-for the type definitions. The `macros <macros.html>`_ module contains many
+for the type definitions. The [macros](macros.html) module contains many
 examples how the AST represents each syntactic structure.
 
 
@@ -324,15 +324,15 @@ ARC/ORC. The new runtime is active `when defined(nimV2)`.
 Coding Guidelines
 =================
 
-* We follow Nim's official style guide, see `<nep1.html>`_.
+* We follow Nim's official style guide, see [NEP1](nep1.html).
 * Max line length is 100 characters.
 * Provide spaces around binary operators if that enhances readability.
 * Use a space after a colon, but not before it.
 * (deprecated) Start types with a capital `T`, unless they are
   pointers/references which start with `P`.
 * Prefer `import package`:nim: over `from package import symbol`:nim:.
 
-See also the `API naming design <apis.html>`_ document.
+See also the [API naming design](apis.html) document.
 
 
 Porting to new platforms
@@ -452,7 +452,7 @@ could stem from a complex expression:
   receivesClosure(returnsDefaultCC[i])
   ```
 
-A thunk would need to call 'returnsDefaultCC[i]' somehow and that would require
+A thunk would need to call `returnsDefaultCC[i]` somehow and that would require
 an *additional* closure generation... Ok, not really, but it requires to pass
 the function to call. So we'd end up with 2 indirect calls instead of one.
 Another much more severe problem with this solution is that it's not GC-safe

doc/koch.md

@@ -48,16 +48,16 @@ csource command
 ---------------
 
 The `csource`:idx: command builds the C sources for installation. It accepts
-the same options as you would pass to the `boot command
-<#commands-boot-command>`_.
+the same options as you would pass to the [boot command](
+#commands-boot-command).
 
 temp command
 ------------
 
 The temp command builds the Nim compiler but with a different final name
 (`nim_temp`:cmd:), so it doesn't overwrite your normal compiler. You can use
-this command to test different options, the same you would issue for the `boot
-command <#commands-boot-command>`_.
+this command to test different options, the same you would issue for the [boot
+command](#commands-boot-command).
 
 test command
 ------------
@@ -88,4 +88,4 @@ pdf command
 
 The `pdf`:idx: command builds PDF versions of Nim documentation: Manual,
 Tutorial and a few other documents. To run it one needs to
-`install Latex/xelatex <https://www.latex-project.org/get>`_ first.
+[install Latex/xelatex](https://www.latex-project.org/get) first.