You mean it's sensitive to the existance of a file that might be the target of the link? So L<foo> would figure out I meant foo.html in the same directory, if there is a foo.html in that directory?

As for subclassing, I know I could make it work in my own custom solution, but people will be running the regular pod2html, not my custom job. And ActiveState's doc engine and search.cpan's doc engine does things their way, too.

I wondered if any documentation or lore existed on details of those, or the existance of =for directives they know.

—John

L<foo> would never look for a foo.html in that directory. It would look for (for example) \html\lib\foo.html, html\site\lib\foo.html, \html\bin\foo.html, and maybe a few others (like perl -V:installsitebin -V:installuserbin).

Please read perlpod and the newer perlpodspec for details on how to use L<> tag (or at least how it's supposed to work).

Implementation should be sensitive to the existence of the target file. I probably misspoke earlier, about it being a chicken and egg problem with Pod::Html specifically (I have enhanced my copy of Pod::Html a few times).

You should not concern yourself what'll happen if the user don't have the docs for a target (or the module itself).

Just avoid whatever you thought you might be able to do using =for directives (don't do it) and stick to L<> tags, they're portable (given you use them properl, but it's easy).

update: I did some testing, and it is a chicken and egg problem, but it doesn't always happen. I ran into it during HTML::Mason installation. I also discovered a bug, L<HTML::Mason> will resolve into L<Bundle::HTML::Mason>. I'm gonna have to fix that, and submit a patch.

MJD says you can't just make shit up and expect the computer to know what you mean, retardo! ** The Third rule of perl club is a statement of fact: pod is sexy.