TO DO
 =====

 SHORT TERM
 ----------
 * Remove Pod::PlainText from the PodParser distribution once it has
   replaced Pod::Text (in functin and in name) in the latest stable
   Perl distribution (this is slated to happen for Perl 5.6, its currently
   in 5.005_58 now but thats stil considered a development versin rather
   than "stable").

 * Make the test-suite more portable (for Mac + VMS + NT) without having
   to use lots of ugly conditional code. There has to be a better way
   to to dissect and reconstruct filepaths than what 5.004 currently
   offers.

 * Add the ability to use callbacks _instead_ _of_ inheritance if so
   desired (or mix+match 'em as you wish). This means that there should
   be a way to use callbacks instead of inheritance for the equivalent
   of each of the abstract base class methods that do text processing
   (like preprocess_xxxxx and {begin,end}_xxxx and others). This will go
   into a module named Pod::Callbacks.

 * IMPROVE PERFORMANCE!!! (its getting kind of slow)

 * Implement -ranges "option" to Pod::Select & podselect


 LONG TERM
 ---------

 * Maybe create a Pod::Compiler class that reads a POD and returns a
   list of Pod::Paragraphs objects?

 * Make changes necessary to accommodate Kenneth Albanowski's Pod::Simplify
   module so that it may use Pod::Parser.

 * See about providing the ability (perhaps via constructor options) to turn
   off certain unwanted Pod::Parser features in order to improve performance
   (things like calling preprocess_xxx() methods and/or some other "virtual"
   member function calls that a subclass might not want to make use of).

 * Try to allow the user to provide a callback function/method which could
   be used in place of the parse_paragraph() method and/or the command(),
   verbatim(), and textblock() methods.  Such a callback might be provided
   as a constructor argument to Pod::Parser.  Perhaps it might be possible
   to pass the callback method an array of lines or of paragraphs (rather
   than one input block at a time) if certain options are specified.

 * In Pod::Checker, check that =encoding specifies a valid encoding;
   possibly by using the Encode module?

 * Add a check of Perl core pods (as suggested by M. Schwern):
   The follow test runs each pod/*.pod file through Pod::Checker and fails
   if there are any warnings or errors.  There are a handful of errors and 
   huge amounts of warnings.
   This patch should not be applied to the main sources until the warnings 
   are cleaned up.

--- t/pod/corepods.t	2002/12/10 22:36:52	1.1
+++ t/pod/corepods.t	2002/12/10 23:21:25
@@ -0,0 +1,22 @@
+#!perl -w
+
+BEGIN {
+    chdir 't';
+    @INC = '../lib';
+}
+
+use Pod::Checker;
+use Test::More;
+use File::Spec;
+
+chdir File::Spec->updir;
+my @podfiles = glob "pod/*.pod";
+plan tests => scalar @podfiles;
+
+my $checker = Pod::Checker->new;
+
+foreach my $podfile (@podfiles) {
+    $checker->parse_from_file($podfile, \*STDERR);
+    is( $checker->num_errors,   0, "podchecker $podfile error check" );
+    is( $checker->num_warnings, 0, "podchecker $podfile warnings check" );
+}



Pod::Checker etc.:

Brad:

 * I do not think there should ever be any complaint about the first
   =pod directive being something other than =head (or other than =pod and
   =head) unless some kind of '-strictmanpagestyle' option is set. There is
   no law that says the beginning of ever document has to be a heading.
   Sometimes it useful to have an untitled intro. Now it *is* true that any
   manpage should start with a heading, but not any POD document in general.

   => implement '-manpage' option for Pod::Checker?

Wolfgang Laun:

 * =over/=back without intervening =item produces a warning even when
   there are pararaphs in between. But this could be used to produce
   indented paragraphs. Restrict warning to completely empty lists?

   => is this legal POD at all? Currently a warning is printed