diff --git a/doc/manual/generics.txt b/doc/manual/generics.txt
index 1ba62bb5ca..09fecbd959 100644
--- a/doc/manual/generics.txt
+++ b/doc/manual/generics.txt
@@ -314,7 +314,7 @@ The concept types can be parametric just like the regular generic types:
 
 .. code-block:: nim
   ### matrixalgo.nim
-  
+
   import typetraits
 
   type
@@ -360,7 +360,7 @@ The concept types can be parametric just like the regular generic types:
   template Rows*(M: type Matrix): expr = M.M
   template Cols*(M: type Matrix): expr = M.N
   template ValueType*(M: type Matrix): typedesc = M.T
-  
+
   -------------
   ### usage.nim
 
@@ -582,60 +582,61 @@ the concept body:
   proc log(format: static[string], varargs[distinct StringRef])
 
 
-VTable types
-------------
+..
+  VTable types
+  ------------
 
-Concepts allow Nim to define a great number of algorithms, using only
-static polymorphism and without erasing any type information or sacrificing
-any execution speed. But when polymorphic collections of objects are required,
-the user must use one of the provided type erasure techniques - either common
-base types or VTable types.
+  Concepts allow Nim to define a great number of algorithms, using only
+  static polymorphism and without erasing any type information or sacrificing
+  any execution speed. But when polymorphic collections of objects are required,
+  the user must use one of the provided type erasure techniques - either common
+  base types or VTable types.
 
-VTable types are represented as "fat pointers" storing a reference to an
-object together with a reference to a table of procs implementing a set of
-required operations (the so called vtable).
+  VTable types are represented as "fat pointers" storing a reference to an
+  object together with a reference to a table of procs implementing a set of
+  required operations (the so called vtable).
 
-In contrast to other programming languages, the vtable in Nim is stored
-externally to the object, allowing you to create multiple different vtable
-views for the same object. Thus, the polymorphism in Nim is unbounded -
-any type can implement an unlimited number of protocols or interfaces not
-originally envisioned by the type's author.
+  In contrast to other programming languages, the vtable in Nim is stored
+  externally to the object, allowing you to create multiple different vtable
+  views for the same object. Thus, the polymorphism in Nim is unbounded -
+  any type can implement an unlimited number of protocols or interfaces not
+  originally envisioned by the type's author.
 
-Any concept type can be turned into a VTable type by using the ``vtref``
-or the ``vtptr`` compiler magics. Under the hood, these magics generate
-a converter type class, which converts the regular instances of the matching
-types to the corresponding VTable type.
+  Any concept type can be turned into a VTable type by using the ``vtref``
+  or the ``vtptr`` compiler magics. Under the hood, these magics generate
+  a converter type class, which converts the regular instances of the matching
+  types to the corresponding VTable type.
 
-.. code-block:: nim
-  type
-    IntEnumerable = vtref Enumerable[int]
+  .. code-block:: nim
+    type
+      IntEnumerable = vtref Enumerable[int]
 
-    MyObject = object
-      enumerables: seq[IntEnumerable]
-      streams: seq[OutputStream.vtref]
+      MyObject = object
+        enumerables: seq[IntEnumerable]
+        streams: seq[OutputStream.vtref]
 
-  proc addEnumerable(o: var MyObject, e: IntEnumerable) =
-    o.enumerables.add e
+    proc addEnumerable(o: var MyObject, e: IntEnumerable) =
+      o.enumerables.add e
 
-  proc addStream(o: var MyObject, e: OutputStream.vtref) =
-    o.streams.add e
+    proc addStream(o: var MyObject, e: OutputStream.vtref) =
+      o.streams.add e
 
-The procs that will be included in the vtable are derived from the concept
-body and include all proc calls for which all param types were specified as
-concrete types. All such calls should include exactly one param of the type
-matched against the concept (not necessarily in the first position), which
-will be considered the value bound to the vtable.
+  The procs that will be included in the vtable are derived from the concept
+  body and include all proc calls for which all param types were specified as
+  concrete types. All such calls should include exactly one param of the type
+  matched against the concept (not necessarily in the first position), which
+  will be considered the value bound to the vtable.
 
-Overloads will be created for all captured procs, accepting the vtable type
-in the position of the captured underlying object.
+  Overloads will be created for all captured procs, accepting the vtable type
+  in the position of the captured underlying object.
 
-Under these rules, it's possible to obtain a vtable type for a concept with
-unbound type parameters or one instantiated with metatypes (type classes),
-but it will include a smaller number of captured procs. A completely empty
-vtable will be reported as an error.
+  Under these rules, it's possible to obtain a vtable type for a concept with
+  unbound type parameters or one instantiated with metatypes (type classes),
+  but it will include a smaller number of captured procs. A completely empty
+  vtable will be reported as an error.
 
-The ``vtref`` magic produces types which can be bound to ``ref`` types and
-the ``vtptr`` magic produced types bound to ``ptr`` types.
+  The ``vtref`` magic produces types which can be bound to ``ref`` types and
+  the ``vtptr`` magic produced types bound to ``ptr`` types.
 
 
 Symbol lookup in generics