Fix a number of typos in the documentation

While reading the docs, I saw a few typos, so I ran ispell through the
docs. Fixed:

- plain typos
- a few instances of 'ie'→'i.e.' and 'eg' → 'e.g.' for nicer style
- a few capitalisation issues (linux, unix)
- a few not-nice (IMHO) abbreviations (for a manual, that is):
  distro→distribution, repo→repository
- proper naming (RedHat→Red Hat)

Cabal/doc/developing-packages.markdown

@@ -349,7 +349,7 @@ automatic package management. This means tools like `cabal` can resolve
 dependencies and install a package plus all of its dependencies
 automatically. Alternatively, it is possible to mechanically (or mostly
 mechanically) translate Cabal packages into system packages and let the
-system package managager install dependencies automatically.
+system package manager install dependencies automatically.
 
 It is important to track dependencies accurately so that packages can
 reliably be moved from one system to another system and still be able to
@@ -362,15 +362,15 @@ could cause the code to fail to build on some other system.
 
 The explicit dependency approach is in contrast to the traditional
 "./configure" approach where instead of specifying dependencies
-declarativly, the `./configure` script checks if the dependencies are
+declaratively, the `./configure` script checks if the dependencies are
 present on the system. Some manual work is required to transform a
 `./configure` based package into a Linux distribution package (or
 similar). This conversion work is usually done by people other than the
 package author(s). The practical effect of this is that only the most
-popular packages will benefit from automatic package managment. Instead,
+popular packages will benefit from automatic package management. Instead,
 Cabal forces the original author to specify the dependencies but the
 advantage is that every package can benefit from automatic package
-managment.
+management.
 
 The "./configure" approach tends to encourage packages that adapt
 themselves to the environment in which they are built, for example by
@@ -378,7 +378,7 @@ disabling optional features so that they can continue to work when a
 particular dependency is not available. This approach makes sense in a
 world where installing additional dependencies is a tiresome manual
 process and so minimising dependencies is important. The automatic
-package managment view is that packages should just declare what they
+package management view is that packages should just declare what they
 need and the package manager will take responsibility for ensuring that
 all the dependencies are installed.
 
@@ -417,7 +417,7 @@ that are needed and the build system will take care of using the right
 flags for the compiler. Additionally this makes it easier for tools to
 discover what system C libraries a package needs, which is useful for
 tracking dependencies on system libraries (e.g. when translating into
-linux distro packages).
+Linux distribution packages).
 
 In fact both of these examples fall into the category of explicitly
 specifying dependencies. Not all dependencies are other Cabal packages.
@@ -447,7 +447,7 @@ very well; if the executables depend on the library, they must
 explicitly list all the modules they directly or indirectly import from
 that library.  Fortunately, starting with Cabal 1.8.0.4, executables can
 also declare the package that they are in as a dependency, and Cabal
-will treat them as if they were in another package that dependended on
+will treat them as if they were in another package that depended on
 the library.
 
 Internally, the package may consist of much more than a bunch of Haskell
@@ -730,7 +730,7 @@ describe the package as a whole:
 
 `cabal-version:`  _>= x.y_
 :   The version of the Cabal specification that this package description uses.
-    The Cabal specification does slowly evolve, intoducing new features and
+    The Cabal specification does slowly evolve, introducing new features and
     occasionally changing the meaning of existing features. By specifying
     which version of the spec you are using it enables programs which process
     the package description to know what syntax to expect and what each part
@@ -741,8 +741,8 @@ describe the package as a whole:
     bounds do not make sense. In future this field will specify just a version
     number, rather than a version range.
 
-    The version number you specify will affect both compatability and
-    behaviour. Most tools (including the Cabal libray and cabal program)
+    The version number you specify will affect both compatibility and
+    behaviour. Most tools (including the Cabal library and cabal program)
     understand a range of versions of the Cabal specification. Older tools
     will of course only work with older versions of the Cabal specification.
     Most of the time, tools that are too old will recognise this fact and
@@ -757,7 +757,7 @@ describe the package as a whole:
     In particular, the syntax of package descriptions changed significantly
     with Cabal version 1.2 and the `cabal-version` field is now required.
     Files written in the old syntax are still recognized, so if you require
-    compatability with very old Cabal versions then you may write your package
+    compatibility with very old Cabal versions then you may write your package
     description file using the old syntax.  Please consult the user's guide of
     an older Cabal version for a description of that syntax.
 
@@ -837,7 +837,7 @@ describe the package as a whole:
 `bug-reports:` _URL_
 :   The URL where users should direct bug reports. This would normally be either:
 
-    * A `mailto:` URL, eg for a person or a mailing list.
+    * A `mailto:` URL, e.g. for a person or a mailing list.
 
     * An `http:` (or `https:`) URL for an online bug tracking system.
 
@@ -1743,7 +1743,7 @@ are currently two kinds defined:
 
 You can specify one kind or the other or both. As an example here are
 the repositories for the Cabal library. Note that the `this` kind of
-repo specifies a tag.
+repository specifies a tag.
 
 ~~~~~~~~~~~~~~~~
 source-repository head
@@ -1787,8 +1787,8 @@ The exact fields are as follows:
 :   CVS requires a named module, as each CVS server can host multiple
     named repositories.
 
-    This field is required for the CVS repo type and should not be used
-    otherwise.
+    This field is required for the CVS repository type and should not
+    be used otherwise.
 
 `branch:` _token_
 :   Many source control systems support the notion of a branch, as a
@@ -1801,17 +1801,17 @@ The exact fields are as follows:
 
 `tag:` _token_
 :   A tag identifies a particular state of a source repository. The tag
-    can be used with a `this` repo kind to identify the state of a repo
-    corresponding to a particular package version or release. The exact
-    form of the tag depends on the repository type.
+    can be used with a `this` repository kind to identify the state of
+    a repository corresponding to a particular package version or
+    release. The exact form of the tag depends on the repository type.
 
-    This field is required for the `this` repo kind.
+    This field is required for the `this` repository kind.
 
 `subdir:` _directory_
 :   Some projects put the sources for multiple packages under a single
     source repository. This field lets you specify the relative path
     from the root of the repository to the top directory for the
-    package, ie the directory containing the package's `.cabal` file.
+    package, i.e. the directory containing the package's `.cabal` file.
 
     This field is optional. It default to empty which corresponds to the
     root directory of the repository.
@@ -1834,7 +1834,7 @@ The `get` command supports the following options:
 
 `-s --source-repository` _[head|this|...]_
 :   Fork the package's source repository using the appropriate version control
-    system. The optional argument allows to choose a specific repo kind.
+    system. The optional argument allows to choose a specific repository kind.
 
 
 ## Accessing data files from package code ##

Cabal/doc/index.markdown

@@ -163,7 +163,7 @@ Cabal is often compared with autoconf and automake and there is some
 overlap in functionality. The most obvious similarity is that the
 command line interface for actually configuring and building packages
 follows the same steps and has many of the same configuration
-paramaters.
+parameters.
 
 ~~~~~~~~~~
 ./configure --prefix=...
@@ -182,7 +182,7 @@ cabal install
 Cabal's build system for simple packages is considerably less flexible
 than make/automake, but has builtin knowledge of how to build Haskell
 code and requires very little manual configuration. Cabal's simple build
-system is also portable to Windows, without needing a unix-like
+system is also portable to Windows, without needing a Unix-like
 environment such as cygwin/mingwin.
 
 Compared to autoconf, Cabal takes a somewhat different approach to

Cabal/doc/installing-packages.markdown

@@ -216,7 +216,7 @@ $ cabal --ignore-sandbox install text
 
 ## Creating a binary package ##
 
-When creating binary packages (e.g. for RedHat or Debian) one needs to
+When creating binary packages (e.g. for Red Hat or Debian) one needs to
 create a tarball that can be sent to another system for unpacking in the
 root directory:
 
@@ -316,7 +316,7 @@ files of a package:
 :   Specify additional options to the program _prog_. Any program known
     to Cabal can be used in place of _prog_. For example:
     `--alex-options="--template=mytemplatedir/"`. The _options_ is split
-    into program options based on spaces. Any options containing embeded
+    into program options based on spaces. Any options containing embedded
     spaced need to be quoted, for example
     `--foo-options='--bar="C:\Program File\Bar"'`. As an alternative
     that takes only one option at a time but avoids the need to quote,
@@ -324,8 +324,8 @@ files of a package:
 
 `--`_`prog`_`-option=`_option_
 :   Specify a single additional option to the program _prog_. For
-    passing an option that contain embeded spaces, such as a file name
-    with embeded spaces, using this rather than `--`_`prog`_`-options`
+    passing an option that contain embedded spaces, such as a file name
+    with embedded spaces, using this rather than `--`_`prog`_`-options`
     means you do not need an additional level of quoting. Of course if
     you are using a command shell you may still need to quote, for
     example `--foo-options="--bar=C:\Program File\Bar"`.
@@ -445,7 +445,7 @@ independence](#prefix-independence)).
 
 `$prefix`
 :   The path variable that stands for the root of the installation. For
-    an installation to be relocatable, all other instllation paths must
+    an installation to be relocatable, all other installation paths must
     be relative to the `$prefix` variable.
 
 `$bindir`
@@ -468,23 +468,23 @@ independence](#prefix-independence)).
 :   As above but for `--docdir`
 
 `$pkgid`
-:   The name and version of the package, eg `mypkg-0.2`
+:   The name and version of the package, e.g. `mypkg-0.2`
 
 `$pkg`
-:   The name of the package, eg `mypkg`
+:   The name of the package, e.g. `mypkg`
 
 `$version`
-:   The version of the package, eg `0.2`
+:   The version of the package, e.g. `0.2`
 
 `$compiler`
-:   The compiler being used to build the package, eg `ghc-6.6.1`
+:   The compiler being used to build the package, e.g. `ghc-6.6.1`
 
 `$os`
 :   The operating system of the computer being used to build the
-    package, eg `linux`, `windows`, `osx`, `freebsd` or `solaris`
+    package, e.g. `linux`, `windows`, `osx`, `freebsd` or `solaris`
 
 `$arch`
-:   The architecture of the computer being used to build the package, eg
+:   The architecture of the computer being used to build the package, e.g.
     `i386`, `x86_64`, `ppc` or `sparc`
 
 #### Paths in the simple build system ####
@@ -584,7 +584,7 @@ be controlled with the following command line options.
 :   (default) Does a global installation. In this case package
     dependencies must be satisfied by the global package database. All
     packages in the user's package database will be ignored. Typically
-    the final instllation step will require administrative privileges.
+    the final installation step will require administrative privileges.
 
 `--package-db=`_db_
 :   Allows package dependencies to be satisfied from this additional
@@ -675,7 +675,7 @@ be controlled with the following command line options.
     example if you want to debug the C parts of a program containing
     both Haskell and C code. Another reason is if your are building a
     package for a system which has a policy of managing the stripping
-    itself (such as some linux distributions).
+    itself (such as some Linux distributions).
 
 `--enable-shared`
 :   Build shared library. This implies a separate compiler run to