Get rid of footnotes

Markdown doesn't support them.

doc/manual/src/expressions/build-script.md

@@ -19,10 +19,9 @@ steps to elucidate what a builder does. It performs the following steps:
 
 1.  When Nix runs a builder, it initially completely clears the
     environment (except for the attributes declared in the derivation).
-    For instance, the `PATH` variable is empty\[1\]. This is done to
-    prevent undeclared inputs from being used in the build process. If
-    for example the `PATH` contained `/usr/bin`, then you might
-    accidentally use `/usr/bin/gcc`.
+    This is done to prevent undeclared inputs from being used in the
+    build process. If for example the `PATH` contained `/usr/bin`, then
+    you might accidentally use `/usr/bin/gcc`.
     
     So the first step is to set up the environment. This is done by
     calling the `setup` script of the standard environment. The
@@ -67,6 +66,3 @@ If you are wondering about the absence of error checking on the result
 of various commands called in the builder: this is because the shell
 script is evaluated with Bash's `-e` option, which causes the script to
 be aborted if any command fails without an error check.
-
-1.  Actually, it's initialised to `/path-not-set` to prevent Bash from
-    setting it to a default value.

doc/manual/src/expressions/derivations.md

@@ -5,11 +5,12 @@ describe a single derivation (a build action). It takes as input a set,
 the attributes of which specify the inputs of the build.
 
   - There must be an attribute named `system` whose value must be a
-    string specifying a Nix platform identifier, such as `"i686-linux"`
-    or `"x86_64-darwin"`\[1\] The build can only be performed on a
-    machine and operating system matching the platform identifier. (Nix
-    can automatically forward builds for other platforms by forwarding
-    them to other machines; see [???](#chap-distributed-builds).)
+    string specifying a Nix system type, such as `"i686-linux"` or
+    `"x86_64-darwin"`. (To figure out your system type, run `nix -vv
+    --version`.) The build can only be performed on a machine and
+    operating system matching the system type. (Nix can automatically
+    forward builds for other platforms by forwarding them to other
+    machines; see [???](#chap-distributed-builds).)
 
   - There must be an attribute named `name` whose value must be a
     string. This is used as a symbolic name for the package by
@@ -146,9 +147,3 @@ The builder is executed as follows:
     supported by Nix. This is because the Nix archives used in
     deployment have no concept of ownership information, and because it
     makes the build result dependent on the user performing the build.
-
-<!-- end list -->
-
-1.  To figure out your platform identifier, look at the line “Checking
-    for the canonical Nix system name” in the output of Nix's
-    `configure` script.

doc/manual/src/expressions/generic-builder.md

@@ -27,8 +27,12 @@ Here is what each line means:
 1.  The `buildInputs` variable tells `setup` to use the indicated
     packages as “inputs”. This means that if a package provides a `bin`
     subdirectory, it's added to `PATH`; if it has a `include`
-    subdirectory, it's added to GCC's header search path; and so
-    on.\[1\]
+    subdirectory, it's added to GCC's header search path; and so on.
+    (This is implemented in a modular way: `setup` tries to source the
+    file `pkg/nix-support/setup-hook` of all dependencies. These “setup
+    hooks” can then set up whatever environment variables they want; for
+    instance, the setup hook for Perl sets the `PERL5LIB` environment
+    variable to contain the `lib/site_perl` directories of all inputs.)
 
 2.  The function `genericBuild` is defined in the file `$stdenv/setup`.
 
@@ -55,10 +59,3 @@ shorter:
 In fact, `mkDerivation` provides a default builder that looks exactly
 like that, so it is actually possible to omit the builder for Hello
 entirely.
-
-1.  How does it work? `setup` tries to source the file
-    `pkg/nix-support/setup-hook` of all dependencies. These “setup
-    hooks” can then set up whatever environment variables they want;
-    for instance, the setup hook for Perl sets the `PERL5LIB`
-    environment variable to contain the `lib/site_perl` directories of
-    all inputs.

doc/manual/src/expressions/language-constructs.md

@@ -17,14 +17,14 @@ would be invalid if no such variable exists. That is, in a normal
 recursive set, they are.
 
 Recursive sets of course introduce the danger of infinite recursion. For
-example,
+example, the expression
 
     rec {
       x = y;
       y = x;
     }.x
 
-does not terminate\[1\].
+will crash with an `infinite recursion encountered` error message.
 
 ## Let-expressions
 
@@ -304,6 +304,3 @@ establishes the same scope as
 Comments can be single-line, started with a `#` character, or
 inline/multi-line, enclosed within `/*
 ... */`.
-
-1.  Actually, Nix detects infinite recursion in this case and aborts
-    (“infinite recursion encountered”).

doc/manual/src/expressions/language-values.md

@@ -108,12 +108,14 @@ Nix has the following basic data types:
     floating point number will have a floating point number as a result.
 
   - *Paths*, e.g., `/bin/sh` or `./builder.sh`. A path must contain at
-    least one slash to be recognised as such; for instance, `builder.sh`
-    is not a path\[1\]. If the file name is relative, i.e., if it does
-    not begin with a slash, it is made absolute at parse time relative
-    to the directory of the Nix expression that contained it. For
-    instance, if a Nix expression in `/foo/bar/bla.nix` refers to
-    `../xyzzy/fnord.nix`, the absolute path is `/foo/xyzzy/fnord.nix`.
+    least one slash to be recognised as such. For instance, `builder.sh`
+    is not a path: it's parsed as an expression that selects the
+    attribute `sh` from the variable `builder`. If the file name is
+    relative, i.e., if it does not begin with a slash, it is made
+    absolute at parse time relative to the directory of the Nix
+    expression that contained it. For instance, if a Nix expression in
+    `/foo/bar/bla.nix` refers to `../xyzzy/fnord.nix`, the absolute path
+    is `/foo/xyzzy/fnord.nix`.
     
     If the first component of a path is a `~`, it is interpreted as if
     the rest of the path were relative to the user's home directory.
@@ -122,8 +124,8 @@ Nix has the following basic data types:
     
     Paths can also be specified between angle brackets, e.g.
     `<nixpkgs>`. This means that the directories listed in the
-    environment variable NIX\_PATH\</literal\> will be searched for the
-    given file or directory name.
+    environment variable `NIX_PATH` will be searched for the given file
+    or directory name.
 
   - *Booleans* with values `true` and `false`.
 
@@ -210,6 +212,3 @@ passed in first , e.g.,
 evaluates to `2`. This can be used to attach metadata to a function
 without the caller needing to treat it specially, or to implement a form
 of object-oriented programming, for example.
-
-1.  It's parsed as an expression that selects the attribute `sh` from
-    the variable `builder`.

doc/manual/src/expressions/simple-expression.md

@@ -12,16 +12,12 @@ do three things:
     describes all the inputs involved in building the package, such as
     dependencies, sources, and so on.
 
-2.  Write a *builder*. This is a shell script\[1\] that actually builds
-    the package from the inputs.
+2.  Write a *builder*. This is a shell script that builds the package
+    from the inputs. (In fact, it can be written in any language, but
+    typically it's a `bash` shell script.)
 
 3.  Add the package to the file `pkgs/top-level/all-packages.nix`. The
     Nix expression written in the first step is a *function*; it
     requires other packages in order to build it. In this step you put
     it all together, i.e., you call the function with the right
     arguments to build the actual package.
-
-<!-- end list -->
-
-1.  In fact, it can be written in any language, but typically it's a
-    `bash` shell script.