Fix typos

doc/backends.txt

@@ -225,7 +225,7 @@ The JavaScript target doesn't have any further interfacing considerations
 since it also has garbage collection, but the C targets require you to
 initialize Nim's internals, which is done calling a ``NimMain`` function.
 Also, C code requires you to specify a forward declaration for functions or
-the compiler will asume certain types for the return value and parameters
+the compiler will assume certain types for the return value and parameters
 which will likely make your program crash at runtime.
 
 The Nim compiler can generate a C interface header through the ``--header``
@@ -427,7 +427,7 @@ Custom data types
 -----------------
 
 Just like strings, custom data types that are to be shared between Nim and
-the backend will need careful consideration of who controlls who. If you want
+the backend will need careful consideration of who controls who. If you want
 to hand a Nim reference to C code, you will need to use `GC_ref
 <system.html#GC_ref>`_ to mark the reference as used, so it does not get
 freed. And for the C backend you will need to expose the `GC_unref

doc/idetools.txt

@@ -163,7 +163,7 @@ running/debugged user project.
 Compiler as a service (CAAS)
 ============================
 
-The ocasional use of idetools is acceptable for things like
+The occasional use of idetools is acceptable for things like
 definitions, where the user puts the cursor on a symbol or double
 clicks it and after a second or two the IDE displays where that
 symbol is defined. Such latencies would be terrible for features
@@ -533,10 +533,10 @@ run it manually. First you have to compile the tester::
 Running the ``caasdriver`` without parameters will attempt to process
 all the test cases in all three operation modes. If a test succeeds
 nothing will be printed and the process will exit with zero. If any
-test fails, the specific line of the test preceeding the failure
+test fails, the specific line of the test preceding the failure
 and the failure itself will be dumped to stdout, along with a final
 indicator of the success state and operation mode. You can pass the
-parameter ``verbose`` to force all output even on successfull tests.
+parameter ``verbose`` to force all output even on successful tests.
 
 The normal operation mode is called ``ProcRun`` and it involves
 starting a process for each command or query, similar to running

doc/intern.txt

@@ -370,7 +370,7 @@ needed as the data structures needs to be rebuilt periodically anyway.
 
 Complete traversal is done in this way::
 
-  for each page decriptor d:
+  for each page descriptor d:
     for each bit in d:
       if bit == 1:
         traverse the pointer belonging to this bit
@@ -406,7 +406,7 @@ The generated code looks roughly like this:
     setRef(&r->left)
   }
 
-Note that for systems with a continous stack (which most systems have)
+Note that for systems with a continuous stack (which most systems have)
 the check whether the ref is on the stack is very cheap (only two
 comparisons).
 

doc/lib.txt

@@ -370,7 +370,7 @@ Miscellaneous
 -------------
 
 * `events <events.html>`_
-  This module implements an event system that is not dependant on external
+  This module implements an event system that is not dependent on external
   graphical toolkits.
 
 * `oids <oids.html>`_

doc/manual/about.txt

@@ -25,9 +25,9 @@ with ``'``. An example::
 
   ifStmt = 'if' expr ':' stmts ('elif' expr ':' stmts)* ('else' stmts)?
   
-The binary ``^*`` operator is used as a shorthand for 0 or more occurances
+The binary ``^*`` operator is used as a shorthand for 0 or more occurrences
 separated by its second argument; likewise ``^+`` means 1 or more 
-occurances: ``a ^+ b`` is short for ``a (b a)*`` 
+occurrences: ``a ^+ b`` is short for ``a (b a)*`` 
 and ``a ^* b`` is short for ``(a (b a)*)?``. Example::
 
   arrayConstructor = '[' expr ^* ',' ']'

doc/manual/syntax.txt

@@ -59,7 +59,7 @@ Precedence level    Operators                                      First charact
 Strong spaces
 -------------
 
-The number of spaces preceeding a non-keyword operator affects precedence
+The number of spaces preceding a non-keyword operator affects precedence
 if the experimental parser directive ``#!strongSpaces`` is used. Indentation
 is not used to determine the number of spaces. If 2 or more operators have the
 same number of preceding spaces the precedence table applies, so ``1 + 3 * 4``

doc/manual/types.txt

@@ -1142,7 +1142,7 @@ modules like `db_sqlite <db_sqlite.html>`_.
 Void type
 ---------
 
-The ``void`` type denotes the absense of any type. Parameters of
+The ``void`` type denotes the absence of any type. Parameters of
 type ``void`` are treated as non-existent, ``void`` as a return type means that
 the procedure does not return a value:
 

doc/nimc.txt

@@ -134,7 +134,7 @@ found an ambiguity error is produced.
 ``nim dump`` shows the contents of the PATH.
 
 However before the PATH is used the current directory is checked for the
-file's existance. So if PATH contains ``$lib`` and ``$lib/bar`` and the
+file's existence. So if PATH contains ``$lib`` and ``$lib/bar`` and the
 directory structure looks like this::
 
   $lib/x.nim

doc/nimgrep.txt

@@ -25,9 +25,9 @@ Compile nimgrep with the command::
 And copy the executable somewhere in your ``$PATH``.
 
 
-Command line switches
-=====================
-
+Command line switches
+=====================
+
 Usage:
   nimgrep [options] [pattern] [replacement] (file/directory)*
 Options:
@@ -37,7 +37,7 @@ Options:
   --re                pattern is a regular expression (default); extended 
                       syntax for the regular expression is always turned on
   --recursive         process directories recursively
-  --confirm           confirm each occurence/replacement; there is a chance 
+  --confirm           confirm each occurrence/replacement; there is a chance 
                       to abort any time without touching the file
   --stdin             read pattern from stdin (to avoid the shell's confusing
                       quoting rules)

doc/tut2.txt

@@ -37,7 +37,7 @@ Object Oriented Programming
 While Nim's support for object oriented programming (OOP) is minimalistic,
 powerful OOP techniques can be used. OOP is seen as *one* way to design a
 program, not *the only* way. Often a procedural approach leads to simpler
-and more efficient code. In particular, prefering composition over inheritance
+and more efficient code. In particular, preferring composition over inheritance
 is often the better design.
 
 
@@ -142,7 +142,7 @@ An example:
 
 .. code-block:: nim
 
-  # This is an example how an abstract syntax tree could be modeled in Nim
+  # This is an example how an abstract syntax tree could be modelled in Nim
   type
     NodeKind = enum  # the different node types
       nkInt,          # a leaf with an integer value
@@ -335,7 +335,7 @@ As the example demonstrates, invocation of a multi-method cannot be ambiguous:
 Collide 2 is preferred over collide 1 because the resolution works from left to
 right. Thus ``Unit, Thing`` is preferred over ``Thing, Unit``.
 
-**Perfomance note**: Nim does not produce a virtual method table, but
+**Performance note**: Nim does not produce a virtual method table, but
 generates dispatch trees. This avoids the expensive indirect branch for method
 calls and enables inlining. However, other optimizations like compile time
 evaluation or dead code elimination do not work with methods.