korsygfhrtzangaiide

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