diff --git a/doc/test/features.txt b/doc/test/features.txt
index b669df2b1..00442e124 100644
--- a/doc/test/features.txt
+++ b/doc/test/features.txt
@@ -265,7 +265,7 @@ For example, in order to avoid running some tests on Win32::
 generative tests: yielding parametrized tests
 ====================================================
 
-**deprecated since 1.0 in favour of `test generators`_**
+Deprecated since 1.0 in favour of `test generators`_.
 
 *Generative tests* are test methods that are *generator functions* which
 ``yield`` callables and their arguments.  This is useful for running a
diff --git a/doc/test/funcargs.txt b/doc/test/funcargs.txt
index 2db765422..0b1631612 100644
--- a/doc/test/funcargs.txt
+++ b/doc/test/funcargs.txt
@@ -34,7 +34,7 @@ convenient enough to
 
 .. _`blog post about the monkeypatch funcarg`: http://tetamap.wordpress.com/2009/03/03/monkeypatching-in-unit-tests-done-right/
 .. _`xUnit style`: xunit_setup.html 
-.. _`old-style generative tests`: 
+.. _`old-style generative tests`: features.html#generative-tests
 
 .. _`funcarg provider`:
  
@@ -273,7 +273,7 @@ application specific test setup
 
 Here is a basic useful step-wise example for handling application
 specific test setup.  The goal is to have one place where we have the 
-glue code for bootstrapping and configuring application objects and allow
+glue and test support code for bootstrapping and configuring application objects and allow
 test modules and test functions to stay ignorant of involved details. 
 
 step 1: use and implement a test/app-specific "mysetup"
diff --git a/doc/test/plugins.txt b/doc/test/plugins.txt
index ac6c9aa3f..b47bce29b 100644
--- a/doc/test/plugins.txt
+++ b/doc/test/plugins.txt
@@ -53,6 +53,15 @@ py.test loads and configures plugins at tool startup:
 * by loading all plugins specified via a ``pytest_plugins``
   variable in ``conftest.py`` files or test modules. 
 
+Specifying a plugin in a test module or ``conftest.py`` will
+only lead to activitation when ``py.test`` actually sees the
+directory and the file during the collection process.  This is
+already after command line parsing and there is no try to do 
+a "pre-scan of all subdirs" as this would mean a potentially
+very large delay.  As long as you don't add command line options this detail 
+does not need to worry you. 
+
+
 example: ensure a plugin is loaded 
 -----------------------------------