diff --git a/yo/advancedtemplates/append.yo b/yo/advancedtemplates/append.yo
index 3b83388b..f95f6456 100644
--- a/yo/advancedtemplates/append.yo
+++ b/yo/advancedtemplates/append.yo
@@ -3,7 +3,7 @@ recursive template meta programs. Two variadic template structs tt(Append) and
 tt(Prefix) and two specializations are all it takes.
 
     Here are the declarations of the two variadic template structs:
-            verbinsert(STRUCT)(advancedtemplates/examples/append.h)
+            verbinsert(STRUCTS)(advancedtemplates/examples/append.h)
 
     To append or prefix a new type to a typelist specializations expect a
 typelist and a type to add and simply define a new tt(TypeList) also including
diff --git a/yo/advancedtemplates/basenameresolution.yo b/yo/advancedtemplates/basenameresolution.yo
index 4b2d8256..fe958f14 100644
--- a/yo/advancedtemplates/basenameresolution.yo
+++ b/yo/advancedtemplates/basenameresolution.yo
@@ -23,8 +23,8 @@ defined a specialization:
         std::cout << "This is the int-specialization\n";
     }
         )
-    Since the compiler does not know whether a specialization of tt(member)
-will be in effect when tt(Derived<SomeType>::Derived) is called, it can't
+    Since the compiler, when tt(Derived<SomeType>::Derived) is called, does
+not know whether a specialization of tt(member) will be in effect, it can't
 decide (when compiling tt(Derived<T>::Derived)) for what type to instantiate
 tt(member). It can't decide this when compiling tt(Derived<T>::Derived) as
 tt(member)'s call in tt(Derived::Derived) doesn't require a template type
diff --git a/yo/advancedtemplates/eraseall.yo b/yo/advancedtemplates/eraseall.yo
index 5e7d14d3..d0be7335 100644
--- a/yo/advancedtemplates/eraseall.yo
+++ b/yo/advancedtemplates/eraseall.yo
@@ -17,7 +17,7 @@ tt(Erase)'s algorithm:
     it() If tt(TypeList)'s head matches tt(EraseType) tt(EraseAll) is also
         applied to the tt(TypeList)'s tail, thus removing all occurrences of
         tt(EraseType) from tt(TypeList):
-            verbinsert(ALLTYPES)(advancedtemplates/examples/erase.h)
+            verbinsert(ERASEALLTYPES)(advancedtemplates/examples/erase.h)
     it() In all other cases (i.e., tt(TypeList)'s head does em(not) match
         tt(EraseType)) tt(EraseAll) is applied to the tt(TypeList)'s tail.
         The returned tt(TypeList) consists of the original tt(TypeList)'s
diff --git a/yo/advancedtemplates/erasedup.cc b/yo/advancedtemplates/erasedup.yo
similarity index 87%
rename from yo/advancedtemplates/erasedup.cc
rename to yo/advancedtemplates/erasedup.yo
index df9bf843..cbf0a9bc 100644
--- a/yo/advancedtemplates/erasedup.cc
+++ b/yo/advancedtemplates/erasedup.yo
@@ -7,9 +7,9 @@ expects a tt(TypeList):
 declared. tt(EraseDup) structures define a type tt(List) representing the
 tt(TypeList) that they generate. tt(EraseDup) calls expect a tt(TypeList) as
 their template type parameters:
-        verbinsert(ERASEDUP)(advancetemplates/examples/erase.h)
+        verbinsert(ERASEDUP)(advancedtemplates/examples/erase.h)
     it() If the tt(TypeList) is empty it can be returned empty and we're done:
-        verbinsert(ERASEDUPEMPTY)(advancetemplates/examples/erase.h)
+        verbinsert(ERASEDUPEMPTY)(advancedtemplates/examples/erase.h)
     it() In all other cases
         itemization(
         it() tt(EraseDup) is first applied to the original tt(TypeList)'s
@@ -24,7 +24,7 @@ initial type to which the types of the tt(TypeList) produced by the previous
 step are appended.
         )
     This specialization is implemented like this:
-        verbinsert(ERASEDUPHEAD)(advancetemplates/examples/erase.h)
+        verbinsert(ERASEDUPHEAD)(advancedtemplates/examples/erase.h)
     )
     Here is an example showing how tt(EraseDup) can be used:
         verbinsert(ERASEDUP)(advancedtemplates/examples/erase.cc)
diff --git a/yo/advancedtemplates/examples/append.h b/yo/advancedtemplates/examples/append.h
index 6e3320b0..7e698a71 100644
--- a/yo/advancedtemplates/examples/append.h
+++ b/yo/advancedtemplates/examples/append.h
@@ -3,7 +3,7 @@
 
 #include "typelist.h"
 
- //STRUCTS
+//STRUCTS
     template <typename ... Types>
     struct Append;
 
diff --git a/yo/advancedtemplates/examples/multi.h b/yo/advancedtemplates/examples/multi.h
index 81cdfd17..80e5c8b8 100644
--- a/yo/advancedtemplates/examples/multi.h
+++ b/yo/advancedtemplates/examples/multi.h
@@ -7,7 +7,7 @@ struct TypeList
     enum { size = sizeof ... (Types) };
 };
 
-//=VECTOR
+//VECTOR
     template <class Type>
     struct Vector: public std::vector<Type>
     {
@@ -52,7 +52,7 @@ struct TypeList
     };
 //=
 
-//=MULTIBASEDONE
+//MULTIBASEDONE
     template <size_t nr>
     struct MultiBase<nr>
     {};
diff --git a/yo/advancedtemplates/inheritance.yo b/yo/advancedtemplates/inheritance.yo
index fdcdfa42..186e71f0 100644
--- a/yo/advancedtemplates/inheritance.yo
+++ b/yo/advancedtemplates/inheritance.yo
@@ -12,12 +12,12 @@ pointers. tt(Derived const *) can be converted to tt(Base const *) if
 using the following trait class tt(LBaseRDerived). tt(LBaseRDerived) provides
 an enum tt(yes) which is 1 if the left type is a base class of the right type
 and both types are different:
-    verbinsert(LBASERDERIVED)(advancedtemplates/examples/conversion.cc)
+    verbinsert(LBASERDERIVED)(advancedtemplates/examples/conversion.h)
 
     If code should not consider a class to be its own base class, then the
 trait class tt(LBaseRtrulyDerived) can be used to perform a  strict test. This
 trait class adds a test for type-equality:
-    verbinsert(LBASERTRUE)(advancedtemplates/examples/conversion.cc)
+    verbinsert(LBASERTRUE)(advancedtemplates/examples/conversion.h)
     Example: the next statement displays tt(1: 0, 2: 1, 3: 0, 4: 1, 5: 0)
 when executed from a tt(main) function:
     verbinsert(INHERITANCE)(advancedtemplates/examples/conversion.cc)
diff --git a/yo/advancedtemplates/multibase.yo b/yo/advancedtemplates/multibase.yo
index 63bfceb1..ecd8f28e 100644
--- a/yo/advancedtemplates/multibase.yo
+++ b/yo/advancedtemplates/multibase.yo
@@ -12,7 +12,7 @@ tt(UWrap) types. Here is tt(MultiBase)'s generic class declaration:
 
     Two specializations handle all possible tt(MultiBase) invocations. One
 specialization is a recursive template. This template handles the first type
-of tt(MultiBase)'s template parameter pack, and recursively uses itself to
+of tt(MultiBase)'s template parameter pack and recursively uses itself to
 handle the remaining types. The second specialization is invoked once the
 template parameter pack is exhausted and does nothing. Here is the definition
 of the latter specialization:
diff --git a/yo/classtemplates.yo b/yo/classtemplates.yo
index 9d769b58..fc313b93 100644
--- a/yo/classtemplates.yo
+++ b/yo/classtemplates.yo
@@ -24,7 +24,7 @@ sect(Static data members)
 includefile(classtemplates/static)
 
 lsubsect(DISTINGUISH)(Extended use of the keyword `typename')
-includefile(advancedtemplates/typename)
+includefile(classtemplates/typename)
 
 sect(Specializing class templates for deviating types)
 includefile(classtemplates/specialization)
diff --git a/yo/classtemplates/examples/cirque.h b/yo/classtemplates/examples/cirque.h
index d76aece7..3ac91d3d 100644
--- a/yo/classtemplates/examples/cirque.h
+++ b/yo/classtemplates/examples/cirque.h
@@ -63,8 +63,9 @@ class CirQue
     :
         d_size(0),
         d_maxSize(maxSize),
-        d_data(maxSize == 0 ? 0 :
-                static_cast<Data *>(operator new(maxSize * sizeof(Data)))),
+        d_data(maxSize == 0 ? 0 : 
+                    static_cast<Data *>(
+                                operator new(maxSize * sizeof(Data)))),
         d_front(d_data),
         d_back(d_data)
     {}
diff --git a/yo/classtemplates/typename.yo b/yo/classtemplates/typename.yo
index c9424098..b633aac5 100644
--- a/yo/classtemplates/typename.yo
+++ b/yo/classtemplates/typename.yo
@@ -18,9 +18,9 @@ first sight puzzling- error message like:
         )
     The error message is puzzling as it was the programmer's intention to
 declare a pointer to a type tt(Ambiguous) defined within the class template
-tt(Type). But the compiler, when confronted with tt(Type::Ambiguous) may
-interpret the statement in various ways. Clearly it cannot inspect tt(Type)
-itself trying to uncover tt(Type)'s true nature as tt(Type) is a template
+tt(Type). But the compiler, confronted with tt(Type::Ambiguous) may interpret
+the statement in various ways. Clearly it cannot inspect tt(Type) itself
+trying to uncover tt(Type)'s true nature as tt(Type) is a template
 type. Because of this tt(Type)'s actual definition isn't available yet.
 
     The compiler is confronted with two possibilities: either
diff --git a/yo/concrete.yo b/yo/concrete.yo
index 2d98050d..8517de6e 100644
--- a/yo/concrete.yo
+++ b/yo/concrete.yo
@@ -58,7 +58,8 @@ includefile(concrete/bitwise)
 lsect(A2X)(A text to anything converter)
 includefile(concrete/a2x)
 
-COMMENT(SUPERSEDED BY LAMBDA FUNCTIONS
+COMMENT(
+    SUPERSEDED BY LAMBDA FUNCTIONS
 
     lsect(STLWRAPPERS)(Wrappers for STL algorithms)
     includefile(concrete/wrappers)
diff --git a/yo/cplusplus.yo b/yo/cplusplus.yo
index 58ae7cab..c39bbf54 100644
--- a/yo/cplusplus.yo
+++ b/yo/cplusplus.yo
@@ -117,7 +117,6 @@ COMMENT( 19 )
 lchapter(GENERIC)(The STL Generic Algorithms)
 includefile(generic)
 
-COMMENT(>>>>>>>>>>>>> NEXT <<<<<<<<<<<<<)
 COMMENT( 20 )
 lchapter(TEMPLATES)(Function Templates)
 includefile(functiontemplates)
diff --git a/yo/exceptions/emptythrow.yo b/yo/exceptions/emptythrow.yo
index 7cb4a1c4..a02bd624 100644
--- a/yo/exceptions/emptythrow.yo
+++ b/yo/exceptions/emptythrow.yo
@@ -48,14 +48,14 @@ chapter ref(POLYMORPHISM). The example may be skipped, though, without
 loss of continuity.
 
 A basic exception handling class can be constructed from which specific
-exception types are derived.  Suppose we have a class tt(Exception),
-containing a member function tt(ExceptionType Exception::severity).  This
-member function tells us (little wonder!) the severity of a thrown
-exception. It might be tt(Info, Notice, Warning, Error) or tt(Fatal).  The
-information contained in the exception depends on its severity and is
-processed by a function tt(handle). In addition, all exceptions support a
-member function like ti(textMsg), returning textual information about the
-exception in a tt(string).
+exception types are derived.  Suppose we have a class tt(Exception), having a
+member function tt(ExceptionType Exception::severity).  This member function
+tells us (little wonder!) the severity of a thrown exception. It might be
+tt(Info, Notice, Warning, Error) or tt(Fatal).  The information contained in
+the exception depends on its severity and is processed by a function
+tt(handle). In addition, all exceptions support a member function like
+ti(textMsg), returning textual information about the exception in a
+tt(string).
 
 By defining a polymorphic function tt(handle) it can be made to behave
 differently, depending on the nature of a thrown exception, when called
diff --git a/yo/exceptions/strong.yo b/yo/exceptions/strong.yo
index c2d71624..752c5dc3 100644
--- a/yo/exceptions/strong.yo
+++ b/yo/exceptions/strong.yo
@@ -122,6 +122,6 @@ object. In situations like these the em(one-function-one-responsibility)
 i(rule of thumb) should be kept in mind: a function should have a single, well
 defined responsibility.
 
-The preferred approach therefore is to retrieve tt(PersonDb)'s objects using a
-member like tt(Person const &at(size_t idx) const) and to erase an object
-using a separate member like tt(void PersonData::erase(size_t idx)).
+The preferred approach is to retrieve tt(PersonDb)'s objects using a member
+like tt(Person const &at(size_t idx) const) and to erase an object using a
+member like tt(void PersonData::erase(size_t idx)).
diff --git a/yo/exceptions/throw.yo b/yo/exceptions/throw.yo
index c8b260e9..d4454b9b 100644
--- a/yo/exceptions/throw.yo
+++ b/yo/exceptions/throw.yo
@@ -19,7 +19,7 @@ tt(Object::fun) defines a local tt(Object toThrow), that is
 thrown as an exception. The exception is caught
 in tt(main). But by then the object originally thrown doesn't exist anymore,
 and tt(main) received a copy:
-        verbinsert(exceptions/examples/throw.cc)(PROG)
+        verbinsert(PROG)(exceptions/examples/throw.cc)
     tt(Object)'s copy constructor is special in that it defines its name as
 tt(" (copy)") to which the other object's name is appended. This allow us to
 monitor the construction and destruction of objects more closely.
diff --git a/yo/friends/friendfun.yo b/yo/friends/friendfun.yo
index 80848a89..f14357f7 100644
--- a/yo/friends/friendfun.yo
+++ b/yo/friends/friendfun.yo
@@ -1,4 +1,4 @@
-    In section ref(INSERTEXTRACT) the insertion operator of the class
+    In section ref(EXTRACTORS) the insertion operator of the class
 tt(Person) (cf. section ref(ASSIGNMENT)) was implemented like this:
         verb(
     ostream &operator<<(ostream &out, Person const &person)
diff --git a/yo/functiontemplates/examples/refwrappper.cc b/yo/functiontemplates/examples/refwrap.cc
similarity index 100%
rename from yo/functiontemplates/examples/refwrappper.cc
rename to yo/functiontemplates/examples/refwrap.cc
diff --git a/yo/functiontemplates/referencewrappers.yo b/yo/functiontemplates/referencewrappers.yo
index 8af53907..df285d6b 100644
--- a/yo/functiontemplates/referencewrappers.yo
+++ b/yo/functiontemplates/referencewrappers.yo
@@ -2,7 +2,7 @@ Situations exist where the compiler is unable to infer that a reference rather
 than a value is passed to a template function. In the following example the
 template function tt(outer) receives tt(int x) as its argument and the
 compiler will dutifully infer that tt(Type) is tt(int):
-        verbinsert(INT)(functiontemplates/examples/refwrapper.cc)
+        verbinsert(INT)(functiontemplates/examples/refwrap.cc)
     Compilation will of course fail and the compiler nicely reports the
 inferred type, e.g.:
     verb(
@@ -14,7 +14,7 @@ example. The function tt(call) is a template expecting a function that takes
 an argument which is then itself modified, and a value to pass on to that
 function. Such a function is, e.g., tt(sqrtArg) expecting a reference to a
 tt(double), which is modified by calling tt(std::sqrt).
-        verbinsert(DOUBLE)(functiontemplates/examples/refwrapper.cc)
+        verbinsert(DOUBLE)(functiontemplates/examples/refwrap.cc)
  Assuming tt(double value = 3) then tt(call(sqrtArg, value)) will not modify
 tt(value) as the compiler infers tt(Arg) to be tt(double) and hence passes
 tt(value) by value.
@@ -29,6 +29,6 @@ The C++0x standard offers the ti(CHAR(r)ef(arg)) and ti(cref(arg))
 return it as a reference-typed argument. To actually change tt(value) it can
 be passed to tt(call) using tt(ref(value)) as shown in the following tt(main)
 function:
-        verbinsert(MAIN)(functiontemplates/examples/refwrapper.cc)
+        verbinsert(MAIN)(functiontemplates/examples/refwrap.cc)
  Before using reference wrappers the tthi(functional) header file must have
 been included.
diff --git a/yo/generic/foreach.yo b/yo/generic/foreach.yo
index 7c222143..1efb4c0d 100644
--- a/yo/generic/foreach.yo
+++ b/yo/generic/foreach.yo
@@ -31,8 +31,7 @@ generic algorithms.
 
     The tt(for_each) algorithm cannot directly be used (i.e., by passing
 tt(*this) as the function object argument) inside a member function to modify
-its own object as the tt(for_each) algorithm first creates its own copy of
-the passed function object. A em(wrapper class) whose constructor accepts a
-pointer or reference to the current object and possibly to one of its member
-functions solves this problem. In section ref(STLWRAPPERS) the construction
-of such wrapper classes is described.
+its own object as the tt(for_each) algorithm first creates its own copy of the
+passed function object. A emi(lambda function) or a em(wrapper class) whose
+constructor accepts a pointer or reference to the current object and possibly
+to one of its member functions solves this problem.
diff --git a/yo/polymorphism/base.yo b/yo/polymorphism/base.yo
index 69fcce80..26f6f41a 100644
--- a/yo/polymorphism/base.yo
+++ b/yo/polymorphism/base.yo
@@ -72,7 +72,7 @@ When tt(Second) uses virtual derivation its base class constructor is
 em(ignored) when tt(Second)'s constructor is called from tt(Third). Instead
 tt(Second) will by default call tt(First)'s default constructor. This is
 illustrated by the next example:
-        verbinsert(CLASSES)(polymorhphism/examples/virtualinherit.cc)
+        verbinsert(CLASSES)(polymorphism/examples/virtualinherit.cc)
     When constructing tt(Third) tt(First)'s default constructor is used by
 default. tt(Third)'s constructor, however, may overrule this default behavior
 by explicitly specifying the constructor to use. Since the tt(First) object
diff --git a/yo/polymorphism/multiple.yo b/yo/polymorphism/multiple.yo
index 72d73198..a137fbe2 100644
--- a/yo/polymorphism/multiple.yo
+++ b/yo/polymorphism/multiple.yo
@@ -1,4 +1,4 @@
-In chapter ref(IOStream) we encountered the class tt(fstream), one class
+    In chapter ref(IOStreams) we encountered the class tt(fstream), one class
 offering features of tt(ifstream) and tt(ofstream). In chapter
 ref(INHERITANCE) we learned that a class may be derived from multiple base
 classes. Such a derived class inherits the properties of all its base
diff --git a/yo/stl/autoptr.yo b/yo/stl/autoptr.yo
index 34568913..8f2b85c2 100644
--- a/yo/stl/autoptr.yo
+++ b/yo/stl/autoptr.yo
@@ -1,7 +1,8 @@
-bf(C++) has traditionally offered the (deprecated by the C++0x standard) smart
-pointer class hi(auto_ptr)tt(std::auto_ptr<Type>). This class did not support
-emi(move semantics) although when one tt(auto_ptr) object was assigned to
-another, the right-hand object lost its information.
+The (now deprecated by the C++0x standard) smart pointer class
+hi(auto_ptr)tt(std::auto_ptr<Type>) has traditionally been offered by
+bf(C++). This class does not support emi(move semantics), but when an
+tt(auto_ptr) object is assigned to another, the right-hand object loses its
+information.
 
 The class tt(unique_ptr) does not have tt(auto_ptr)'s drawbacks and
 consequently using tt(auto_ptr) is now deprecated. tt(Auto_ptrs) suffer from
diff --git a/yo/stl/istreamiterators.yo b/yo/stl/istreamiterators.yo
index 0c38abac..8249dbf3 100644
--- a/yo/stl/istreamiterators.yo
+++ b/yo/stl/istreamiterators.yo
@@ -21,4 +21,4 @@ begin-iterator is em(not) mentioned with the default constructor.
     Using tt(back_inserter) and tt(istream_iterator) adaptors, all strings
 from a stream can easily be stored in a container. Example (using i(anonymous)
 tt(istream_iterator) adaptors):
-        verbinclude(stl/cc/istreamiterator.cc)
+        verbinclude(stl/examples/istreamiterator.cc)
diff --git a/yo/stl/mathematical.yo b/yo/stl/mathematical.yo
index d00d1406..89a06070 100644
--- a/yo/stl/mathematical.yo
+++ b/yo/stl/mathematical.yo
@@ -1,8 +1,8 @@
 The following standard distributions are currently available (an example
 showing their use is provided at the end of this section). The reader is
-referred to, e.g., lurl(http://en.wikipedia.org/wiki/Bernoulli_distribution)
-and comparable locations for more information about the distributions
-mentioned below.
+referred to web-locations like
+lurl(http://en.wikipedia.org/wiki/Bernoulli_distribution) for more information
+about the distributions mentioned below.
 
     All distributions offer the following members (em(result_type) refers to
 the type name of the values returned by the distribution;
diff --git a/yo/stl/predefined.yo b/yo/stl/predefined.yo
index 36498dda..4711712e 100644
--- a/yo/stl/predefined.yo
+++ b/yo/stl/predefined.yo
@@ -22,9 +22,8 @@ point. Don't confuse the parentheses in the `tt(greater<string>())' argument
 with calling tt(operator()). When tt(operator()) is actually used inside
 tt(sort), it receives two arguments: two strings to compare for
 `greaterness'. Since tt(greater<string>::operator()) is defined i(inline), the
-call itself is not actually present in the above tt(sort) call.  Rather,
-tt(sort), however, calls tt(string::operator>) through its call of
-tt(greater<string>::operator()).
+call itself is not actually present in the above tt(sort) call.  Instead
+tt(sort) calls tt(string::operator>) through tt(greater<string>::operator()).
 
 Now that we know that a constructor is passed as argument to (many) generic
 algorithms, we can design our own function objects. Assume we want to sort our
diff --git a/yo/stl/sharedptr.yo b/yo/stl/sharedptr.yo
index 02debef5..91e1895d 100644
--- a/yo/stl/sharedptr.yo
+++ b/yo/stl/sharedptr.yo
@@ -1,5 +1,6 @@
-In addition to tt(unique_ptr) the C++0x standard offers a reference counting
-smart pointer: hi(shared_ptr)tt(std::shared_ptr<Type>).
+In addition to tt(unique_ptr) the C++0x standard offers
+hi(shared_ptr)tt(std::shared_ptr<Type>) which is a reference counting smart
+pointer.
 
 The shared pointer will automatically destroy its contents once its reference
 count has decayed to zero.
diff --git a/yo/stl/uniqueplain.yo b/yo/stl/uniqueplain.yo
index 43ac55ab..98a10293 100644
--- a/yo/stl/uniqueplain.yo
+++ b/yo/stl/uniqueplain.yo
@@ -12,4 +12,4 @@ itself is not the pointer, its value em(can) be compared to tt(0). Example:
     if (!ip)
         cout << "0-pointer with a unique_ptr object\n";
         )
-    Alternatively, the member ti(get) can be used (cf. section ref(UNIQUMEM)).
+    Alternatively, the member ti(get) can be used (cf. section ref(UNIQUEMEM)).
diff --git a/yo/whatsnew.yo b/yo/whatsnew.yo
index e62918d3..afb4fa24 100644
--- a/yo/whatsnew.yo
+++ b/yo/whatsnew.yo
@@ -98,7 +98,7 @@ were suggestions I received from various other readers of the bf(C++)
 annotations: all were processed in this release. The bf(C++) content matter of
 this release was not substantially modified, compared to version 6.2.2.
     it() Version 6.2.2 offers improved implementations of the configurable
-class templates (sections ref(WRAPONE) and ref(WRAPTWO)).
+class templates (removed in 8.1.0, superseded by lambda functions).
     it() Version 6.2.0 was released as an Annual Update, by the end of May,
 2005. Apart from the usual typo corrections several new sections
 were added and some were removed: in the Exception chapter (ref(EXCEPTIONS)) a