Index: src/lemon/graph_wrapper.h
===================================================================
--- src/lemon/graph_wrapper.h	(revision 1164)
+++ src/lemon/graph_wrapper.h	(revision 1172)
@@ -35,64 +35,10 @@
   // Graph wrappers
 
-  /*! \addtogroup gwrappers
-    The main parts of LEMON are the different graph structures, 
-    generic graph algorithms, graph concepts which couple these, and 
-    graph wrappers. While the previous ones are more or less clear, the 
-    latter notion needs further explanation.
-    Graph wrappers are graph classes which serve for considering graph 
-    structures in different ways. A short example makes the notion much 
-    clearer. 
-    Suppose that we have an instance \c g of a directed graph
-    type say \c ListGraph and an algorithm 
-    \code template<typename Graph> int algorithm(const Graph&); \endcode 
-    is needed to run on the reversely oriented graph. 
-    It may be expensive (in time or in memory usage) to copy 
-    \c g with the reverse orientation. 
-    Thus, a wrapper class
-    \code template<typename Graph> class RevGraphWrapper; \endcode is used. 
-    The code looks as follows
-    \code
-    ListGraph g;
-    RevGraphWrapper<ListGraph> rgw(g);
-    int result=algorithm(rgw);
-    \endcode
-    After running the algorithm, the original graph \c g 
-    remains untouched. Thus the graph wrapper used above is to consider the 
-    original graph with reverse orientation. 
-    This techniques gives rise to an elegant code, and 
-    based on stable graph wrappers, complex algorithms can be 
-    implemented easily. 
-    In flow, circulation and bipartite matching problems, the residual 
-    graph is of particular importance. Combining a wrapper implementing 
-    this, shortest path algorithms and minimum mean cycle algorithms, 
-    a range of weighted and cardinality optimization algorithms can be 
-    obtained. For lack of space, for other examples, 
-    the interested user is referred to the detailed documentation of graph 
-    wrappers. 
-    The behavior of graph wrappers can be very different. Some of them keep 
-    capabilities of the original graph while in other cases this would be 
-    meaningless. This means that the concepts that they are a model of depend 
-    on the graph wrapper, and the wrapped graph(s). 
-    If an edge of \c rgw is deleted, this is carried out by 
-    deleting the corresponding edge of \c g. But for a residual 
-    graph, this operation has no sense. 
-    Let we stand one more example here to simplify your work. 
-    wrapper class
-    \code template<typename Graph> class RevGraphWrapper; \endcode 
-    has constructor 
-    <tt> RevGraphWrapper(Graph& _g)</tt>. 
-    This means that in a situation, 
-    when a <tt> const ListGraph& </tt> reference to a graph is given, 
-    then it have to be instantiated with <tt>Graph=const ListGraph</tt>.
-    \code
-    int algorithm1(const ListGraph& g) {
-    RevGraphWrapper<const ListGraph> rgw(g);
-    return algorithm2(rgw);
-    }
-    \endcode
-
+  /*!
     \addtogroup gwrappers
     @{
-
+   */
+
+  /*! 
     Base type for the Graph Wrappers
 
Index: src/lemon/maps.h
===================================================================
--- src/lemon/maps.h	(revision 1164)
+++ src/lemon/maps.h	(revision 1172)
@@ -591,5 +591,5 @@
   ///
   ///For the sake of convenience it also works as a ususal map, i.e
-  ///<tt>operator[]</tt> and the \c Key and \c Valu typedefs also exist.
+  ///<tt>operator[]</tt> and the \c Key and \c Value typedefs also exist.
 
   template<class M> 
Index: src/lemon/max_matching.h
===================================================================
--- src/lemon/max_matching.h	(revision 1166)
+++ src/lemon/max_matching.h	(revision 1172)
@@ -162,5 +162,5 @@
     ///have the property that if \c g.oppositeNode(u,map[u])==v then
     ///\c \c g.oppositeNode(v,map[v])==u holds, and now some edge
-    ///joining \c u to \v will be an edge of the matching.
+    ///joining \c u to \c v will be an edge of the matching.
     template<typename NMapE>
     void readNMapEdge(NMapE& map) {
