Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Matts (1087)

Matts
  (email not shown publicly)

I work for MessageLabs [messagelabs.com] in Toronto, ON, Canada. I write spam filters, MTA software, high performance network software, string matching algorithms, and other cool stuff mostly in Perl and C.

Journal of Matts (1087)

Wednesday September 06, 2006
08:16 PM

Pod sucks! Long live Pod!

[ #30911 ]

I got sick and tired of so much vertical whitespace when writing Pod lists. So I wrote, and uploaded to CPAN, XML::Filter::EzPod. It takes any text in an ordinary paragraph and turns lines that start with

/^\*+\s/

into bullet points of the appropriate level, and the same for hashes/pounds (turns them into ordered lists).

It plugs into Pod::SAX, which makes this kind of filter approach really easy.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I agree that is a much more convenient syntax than =item *, but I'm getting a bit concerned about having multiple different POD dialects around, like PseudoPod [cpan.org], SPOD5 [cpan.org] (not a separate POD syntax as such though), forthcoming Perl 6 POD [perl.org] (any news on it, anyone?), pod2pdf [jonallen.info] and so on.

    Surely a =version command should be introduced so that POD parsers can reliably tell if they can process the document? I discussed this with Allison Randal [perl.org] at YAPC::Europe, and apparently the plan is to allow POD documents to specif

    • My approach to this with Pod::WikiDoc [cpan.org] was to explicitly define a Pod format to write in then and pre-process that format into a "canonical" .pod file that is distributed with my modules.

      See my Pod::WikiDoc lightning talk [dagolden.com] for examples.

    • Enforcing use of an =ezpod tag would be easy. I don't mind doing that.

      I probably should have waited for a definitive format, but since it doesn't break anything if you don't pre-process it I didn't see it as a huge issue, and I needed this now.

      (FWIW I modelled the design after Spod5 - but mine allows multiple levels).
    • BTW: There's no new "syntax" in PseudoPod - it seems to me that it behaves like any decent Pod parser should (well, it parses Pod in exactly the same way Pod::SAX does). Not sure why O'Reilly needed to write a new parser for it. Could have done all that with a couple of Pod::SAX plugins.