POD formatting fixes

diff --git a/lib/subs/auto.pm b/lib/subs/auto.pm
index deeec16cf416a8bcb033925922d3f477db8b4e77..decd4f45a58e2aaa73f876067b69087914ed920e 100644 (file)
--- a/lib/subs/auto.pm
+++ b/lib/subs/auto.pm
@@ -51,7 +51,11 @@ You can pass options to C<import> as key / value pairs :
 
 C<< in => $pkg >>
 
-Specifies on which package the pragma should act. Setting C<$pkg> to C<Some::Package> allows you to resolve all functions name of the type C<Some::Package::func ...> in the current scope. You can use the pragma several times with different package names to allow resolution of all the corresponding barewords. Defaults to the current package.
+Specifies on which package the pragma should act.
+Setting C<$pkg> to C<Some::Package> allows you to resolve all functions name of the type C<Some::Package::func ...> in the current scope.
+You can use the pragma several times with different package names to allow resolution of all the corresponding barewords.
+
+Defaults to the current package.
 
 =back
 
@@ -234,9 +238,13 @@ None.
 
 =head1 CAVEATS
 
-C<*{'::foo'}{CODE}> will appear as defined in a scope where the pragma is enabled, C<foo> is used as a bareword, but is never actually defined afterwards. This may or may not be considered as Doing The Right Thing. However, C<*{'::foo'}{CODE}> will always return the right value if you fetch it outside the pragma's scope. Actually, you can make it return the right value even in the pragma's scope by reading C<*{'::foo'}{CODE}> outside (or by actually defining C<foo>, which is ultimately why you use this pragma, right ?).
+C<*{'::foo'}{CODE}> will appear as defined in a scope where the pragma is enabled, C<foo> is used as a bareword, but is never actually defined afterwards.
+This may or may not be considered as Doing The Right Thing.
+However, C<*{'::foo'}{CODE}> will always return the right value if you fetch it outside the pragma's scope.
+Actually, you can make it return the right value even in the pragma's scope by reading C<*{'::foo'}{CODE}> outside (or by actually defining C<foo>, which is ultimately why you use this pragma, right ?).
 
-You have to open global filehandles outside of the scope of this pragma if you want them not to be treated as function calls. Or just use lexical filehandles and default ones as you should be.
+You have to open global filehandles outside of the scope of this pragma if you want them not to be treated as function calls.
+Or just use lexical filehandles and default ones as you should be.
 
 This pragma doesn't propagate into C<eval STRING>.
 
@@ -258,7 +266,8 @@ You can contact me by mail or on C<irc.perl.org> (vincent).
 
 =head1 BUGS
 
-Please report any bugs or feature requests to C<bug-subs-auto at rt.cpan.org>, or through the web interface at L<http://rt.cpan.org/NoAuth/ReportBug.html?Queue=subs-auto>.  I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.
+Please report any bugs or feature requests to C<bug-subs-auto at rt.cpan.org>, or through the web interface at L<http://rt.cpan.org/NoAuth/ReportBug.html?Queue=subs-auto>.
+I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.
 
 =head1 SUPPORT