diff --git a/tren.rst b/tren.rst
index 5f44626..6a67b80 100644
--- a/tren.rst
+++ b/tren.rst
@@ -573,7 +573,28 @@
 Notice that you can stick comments in the file anywhere you like and
 that they begin with ``#``.  Notice also that the various options
 can be entered on separate lines so it's simpler to read the include
-file.  
+file.  If you find it useful, you can even include other include
+files *in* an include file::
+
+  # Get the jpeg -> jpg suffix renaming
+  -I jpeg-to-jpg.tren
+
+  # Let's make it fancy
+
+  -i -1 -r .jpg=.fancy.jpg
+
+If you do this, take care not to create a circular include.  This can
+happen when an include file tries to include itself, either directly,
+or via another include file.  **tren** limits the total number of
+includes to a very large number.  If it sees that the number has been
+exceeded, it suspects a circular include and will issue an error
+message to that effect and exit.
+
+You can insert include options anywhere you like on the command line
+and you can have as many as you like (up to a VERY large number you'll
+never hit in practice).  Each include reference will be replaced with
+the contents of that file *at the position it appears on the command
+line*.
 
 If you find yourself using certain options most- or every time you use
 the program, you can put them in the **$TREN** environment variable.
@@ -780,6 +801,61 @@
   tren.py -i1 -r foo=bar -i2 -r foo=bar foo1-foo2-foo3.foo4
 
 
+More About Command Lines
+========================
+
+As we just saw, you can get surprising results as you process
+the command line from left to right, as **tren** works its way 
+through the various renaming requests.  There are other potential
+pitfalls here, so it's helpful to understand just *how* **tren**
+processes your command line, step-by-step:
+
+  1) Prepend the contents of $TREN to the user-provided command line.
+
+       This allows you to configure your own default set of options
+       so you don't have to type them in every time.
+
+  2) Resolve all references to include files.
+
+       This has to be done before anything that follows, because
+       include files add options to the command line.
+
+  3) Build a table of every file name to be renamed.
+
+       We'll need this information if any of the renaming
+       requests use renaming tokens.
+
+  4) Build a table containg each renaming request storing
+     the current state of every program option at that
+     point on the command line.
+
+       This allows **tren** to apply options differently
+       to different renaming requests on the same command
+       line.  This came in handy in our example of the
+       previous section.
+
+  5) Process each file found on the command line in
+     left to right order, applying every each renaming
+     request, again as it appeared from left to right on
+     the command line.
+
+Simple eh?  Well, mostly it is ... until it isn't.  As we
+just saw, incrementally building up a new name with multiple
+renaming requests can produce unexpected results and we have
+to plan for them.  
+
+Similarly, you can inadvertently rename *the wrong file* ... this is
+usually a Bad Thing.  Say you have two files, ``x`` and ``y``.
+You want to rename ``x`` to ``y`` and ``y`` to ``Y``.  Well, 
+order matters here.  Say you do this::
+
+  tren.py -frx=y -ry=Y x y
+
+**tren** tries to rename ``x`` to ``y`` and spots the fact that ``y`` already
+exists, so it makes a backup, ``y.backup``, and renames ``x`` to ``y`` as
+requested.  TO BE CONTINUED
+
+
 
 Forcing Renaming
 ================
@@ -1529,7 +1605,7 @@
 
 ::
 
-  $Id: tren.rst,v 1.150 2010/03/26 00:17:52 tundra Exp $
+  $Id: tren.rst,v 1.151 2010/03/26 00:57:04 tundra Exp $
 
 You can find the latest version of this program at: