Sean M Burke <[EMAIL PROTECTED]> writes:
> I know there must be a /simple/ way to make a Pod::ParseTree parse tree,
> but I'm not seeing it. In the 5,000 words of Pod::Parser's POD, there's
> a long tractatus about ways to make subclasses that elaborate
> (inarborate?) a Pod::ParseTree. But in the end, it sort of handwaves
> off to Pod::InputObjects -- whose documentation is, to put it
> diplomatically, too much and yet not enough.
Er, not in the version that I have. It specifically tells you how to do
this up to and including giving you code to do it. You override the key
methods (command, verbatim, and textblock) to generate and set
Pod::ParseTree options and then stash your tree somewhere.
There doesn't appear to be any simple way of doing this; you have to
actually write the overrides. (Personally, I'm not sure why you *would*
do this rather than just overriding the core functions, but I assume
you've got some reason to want to do things that way.)
> Maybe I've just not joined the higher primates and come down out of the
> trees, but I think doctrees are they way to go for all but ad-hoc or
> partial processing -- because you can poke and prod and scan and
> rearrange and dump a tree, whereas events just come at you in whatever
> order they get fired in.
Well, I much prefer an event stream, but to each his own.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
