diff --git a/src/wrapper/Plumed.h b/src/wrapper/Plumed.h
index f6e7d6151f435f73b286731722b8d785aa5d1e45..492df237e9e788df141c369872b16aaeb93803f9 100644
--- a/src/wrapper/Plumed.h
+++ b/src/wrapper/Plumed.h
@@ -248,16 +248,18 @@
   As a simple mnemonic, if you know the name of the C function you can obtain the
   corresponding FORTRAN subroutine by adding `F_` after the `PLUMED_` prefix.
   In addition, all `plumed` objects are replaced by `CHARACTER(LEN=32)` objects
-  holding the same information. Finally, whenever a C function returns a value,
+  holding the same information. These pointers basically contain a text representation
+  of the stored pointer, that is suitable to be contained in a string.
+  Finally, whenever a C function returns a value,
   the corresponding FORTRAN subroutine will have an additional `INTENT(OUT)` parameter
   passed as the its last argument.
 
   When you compile the FORTRAN interface, wrapper functions are added with several possible
-  name mangligs, so you should not experience problems linking the plumed library with a FORTRAN file.
+  name manglings, so you should not experience problems linking the plumed library with a FORTRAN file.
 
-\paragraph ReferencePlumedH-exceptions Error handling
+\section ReferencePlumedH-exceptions Error handling
 
-  Bad things happen. In case an error is detected by PLUMED, either because of some user error, some internal bug,
+  In case an error is detected by PLUMED, either because of some user error, some internal bug,
   or some mistake in using the library, an exception will be thrown. The behavior is different depending if you use
   PLUMED from C/FORTRAN or from C++.
 
@@ -280,16 +282,23 @@
   another one, the two std::exception types will differ and you won't be able to catch exceptions raised by PLUMED.
 
   If you use C++ and you are calling the C++ interface (e.g. \ref Plumed::cmd), as of PLUMED 2.5 we implemented a complete
-  remapping of the exceptions thrown by PLUMED. This solves both the problems mentioned above. In particular:
+  remapping of the exceptions thrown by PLUMED.  This solves both the problems mentioned above. In particular:
   - Instead of throwing an exception, PLUMED will return (using a \ref plumed_nothrow_handler) the details about the occurred error.
   - An equivalent exception will be thrown within the inline PLUMED interface compiled with your MD code.
 
   As a consequence, you will be able to combine different compilers and avoid stack unwinding in the C layer.
 
+  Notice that, even if you use \ref Plumed::cmd, if you are loading a kernel <=2.4 any exception generated by PLUMED will
+  leak through the C layer. This might lead to undefined behavior. If you are lucky (with some compiler it works!) and
+  the exception arrives to C, PLUMED will catch it and rethrow it as it would do if you were using a kernel >=2.5.
+
   The remapping of exceptions takes care of all the standard C++ exceptions plus all the exceptions raised within
   PLUMED. Unexpected exceptions that are derived from std::exception will be rethrown as std::exception.
+  Notice that this implies some loss of information, since the original exception might have been of a different type.
+  However, it also implies that the virtual table of the original exception won't be needed anymore. This allows to
+  completely decouple the MD code from the PLUMED library.
 
-\paragraph ReferencePlumedH-2-5 New in PLUMED 2.5
+\section ReferencePlumedH-2-5 New in PLUMED 2.5
 
   The wrappers in PLUMED 2.5 have been completely rewritten with several improvements.
   The interface is almost perfectly backward compatible, although the behavior of C++ constructors