Minor doc fixes

docs/pod/Template/TT3/Manual/Commands.pod

@@ -340,7 +340,7 @@ This does the opposite of encode.
        ...
     [% end %]
 
-=head dot
+=head2 dot
 
 This implements a low-precedence, block oriented form of the dot operator.
 
@@ -417,11 +417,7 @@ inner 'for'.  Ho hum.  This is a good example of why a flexible language
 can be a bad thing.  Flexibility == ambiguity.  I can image things like that 
 tripping people up often, myself included.
 
-Solutions:
-
-=over
-
-=item *
+Possible solutions:
 
 Don't add 'elsif' and 'else' to 'for'.  People aren't expecting 'for' to
 have them, so the natural expectation is that 'elsif' binds to 'if'.  That's
@@ -430,15 +426,11 @@ to 'for' then the above would work because 'for' would reject the 'elsif'
 terminator, consider itself finished and pass control back to 'if' to pick
 up the 'elsif'
 
-=item *
-
 Don't allow follow-on keywords after single expressions.
 
     if x y;                 # OK
     if x y; else z;         # NOT OK 
 
-=item *
-
 Don't allow follow-on keywords after single expressions unless they follow
 immediately, without any terminator.
 

docs/pod/Template/TT3/Manual/Tags.pod

@@ -141,8 +141,8 @@ compile time). TT3 has a new tag style specifically for compile time
 directives. They use C<[?> and C<?]> as delimiters. We call these the "control
 tags".
 
-So to change the inline tag style to use the C<E<lt>*> and C<*E<gt>>
-delimiters, you would write:
+So to change the inline tag style to use different delimiters, you would
+write:
 
     [? TAGS '<* *>' ?]
 
@@ -281,8 +281,8 @@ NOTE: The name of the change_tags() method is subject to change (no pun
 intended).
 
 Custom tags can be particularly useful for doing compile time transformations.
-For example, you can define a tag that starts with C<E<lt>pic:>, ends with
-C<E<gt>> and expects a filename in the middle:
+For example, you can define a tag that starts with "E<lt>pic:", ends with
+"E<gt>" and expects a filename in the middle:
 
     <pic:badger.jpg>
 
@@ -304,10 +304,10 @@ Of course you could always do something like this in TT2:
     [% pic('badger.jpg') %]
 
 The nice thing about tags is that they are (initially) processed when the
-template is compiled. So the <pic:XXX> tag can be expanded when the template
-is compiled and there's no further runtime overhead involved.  Also, by 
-allowing you to define your own syntax for the tag you can keep the tags
-simpler to read and write. 
+template is compiled. So the E<lt>pic:XXXE<gt> tag can be expanded when the
+template is compiled and there's no further runtime overhead involved. Also,
+by allowing you to define your own syntax for the tag you can keep the tags
+simpler to read and write.
 
     <pic:badger.jpg>                # compile time custom tag
 

docs/pod/Template/TT3/TODO.pod

@@ -89,7 +89,7 @@ Figure out what non-chaining infix operators should do.
 =head2 Elements Not Being Loaded
 
 Figure out why element classes aren't being loaded.  e.g. declaring 
-[ TAGS => ctr_tags => 0, 0 ] should load T::TT3::Element::Control::Tags
+[ TAGS =E<gt> ctr_tags =E<gt> 0, 0 ] should load T::TT3::Element::Control::Tags
 and fail if it doesn't exists.  The find() method appears to be returning
 the class name without checking to see if it can be loaded.  (may be fixed?)
 
@@ -116,7 +116,7 @@ and default values (e.g. foo(bar=10) ).
 
 The element base class has evolved a large and complicated set of error 
 method (well, quick hacks to get things working) that need to be cleaned
-up.  The new way is to call $element->fail(), e.g.
+up.  The new way is to call $element-E<gt>fail(), e.g.
 
     $element->fail( syntax_on_fire => $a, $b, $c );
 
@@ -189,7 +189,7 @@ be.  Well, it works for now.
 =head2 Preceding Text
 
 Change the scanner to push the preceding text onto the output tokens before
-calling the tag.  The tag can inspect $output->last if it want to do any 
+calling the tag.  The tag can inspect $output-E<gt>last if it want to do any 
 pre-chomping (see the way the comment tag now works for an example).
 
 =head1 Grammar

lib/Template/TT3/Scanner.pm

@@ -111,6 +111,8 @@ sub scan {
     # create a T::Tokens object to collect output if we weren't passed one
     $output ||= $self->{ tokens }->new($self->{ config });
 
+    $self->debug("scan($text, $output, $scope)") if DEBUG;
+
     $self->reset
         if $self->{ dirty };
 

lib/Template/TT3/Tag.pm

@@ -604,8 +604,6 @@ sub unexpected {
 
 __END__
 
-=pod
-
 =head1 METHODS
 
 =head2 sub tokenise_string($input, $output, $scope, $token, $pos, $content, $delim)
@@ -631,12 +629,13 @@ original chunks. We don't want to inject these into the normal output stream
 because it would then look like they were read from the source, messing up any
 regeneration. So we hang them off the $token->[BRANCH] pointer.
 
-    +-------------------+  BRANCH   +-------------+
-    | dquote:"foo $bar" |---------->| text:"foo " |
-    +-------------------+           +-------------+
-              |                            |  NEXT
-             \|/                          \|/
-             TBA                    +--------------+
-                                    | word:bar     |
-                                    +--------------+
-
+      +-------------------+  BRANCH   +-------------+
+      | dquote:"foo $bar" |---------->| text:"foo " |
+      +-------------------+           +-------------+
+                |                            |  NEXT
+               \|/                          \|/
+               TBA                    +--------------+
+                                      | word:bar     |
+                                      +--------------+
+  
+  

lib/Template/TT3/Tagset.pm

@@ -221,7 +221,7 @@ sub reset {
 
 __END__
 
-=pod
+=head1 METHODS
 
 =head2 init_tagset()
 
@@ -243,26 +243,26 @@ array contents).
 In those cases it's better to be explicit and specify the tags using a list
 reference. That avoids any ambiguity.
 
-   $TAGS = [ inline => { ... }, outline => { ... } ]
+    $TAGS = [ inline => { ... }, outline => { ... } ]
 
 Subsequent entries will not be added to the order. However, the values they
 define will replace those of the earlier occurence. For example:
 
-   $TAGS = [ 
-      inline  => { ... }, 
-      outline => { ... } 
-      inline  => 0,
-   ]
+    $TAGS = [ 
+        inline  => { ... }, 
+        outline => { ... } 
+        inline  => 0,
+    ]
 
 The above ends up being equivalent to:
 
-   $TAGS = [ 
-      inline  => 0, 
-      outline => { ... } 
-   ]
+    $TAGS = [ 
+        inline  => 0, 
+        outline => { ... } 
+    ]
 
 The original order is preserved, but the latter value supersedes the earlier
 one. In this example, the end result is that the inline tag has been disabled.
 Note that we construct the $TAGS list from a number of sources. So the module
 may define the first 'inline' tags, but the user supersedes it by passing the
-'inline => 0' parameter.
+'inline =E<gt> 0' parameter.

lib/Template/TT3/Test.pm

@@ -624,7 +624,7 @@ then you can set the C<has_srm> variable to C<0> or C<1>.
         }
     );
 
-Then your tests can use the <only has_srm> guard clause:
+Then your tests can use the C<only has_srm> guard clause:
 
     -- test Some::Random::Module --
     -- only has_srm --