
 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.

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

 * A =head2 without preceding =head1 might deserve a warning.

