So your issues are with pod2html, less with Pod::Checker. Which pod2html are you using? Likely the issues with hyperlinks should be fixed there.
When looking at the current content of perfunc.pod, it looks like this: 3490 =item open FILEHANDLE,EXPR 3491 X<open> X<pipe> X<file, open> X<fopen> 3492 3493 =item open FILEHANDLE,MODE,EXPR 3494 3495 =item open FILEHANDLE,MODE,EXPR,LIST 3496 3497 =item open FILEHANDLE,MODE,REFERENCE 3498 3499 =item open FILEHANDLE 3500 Which means that if some other POD has L<perfunc/open> in it, it will fail - except that we define that X<open> creates not only an index entry (for those formats and tools that create an index - I did a humble attempt some years ago with Marek::Pod::HTML), but also an anchor. Question to all: neither perlpod nor perlpodspec seem to be clear on whether X<...> should create an anchor at this position for hyperlinks to reference to. I think that would be a sensible thing to specify, since it does not break any existing documents or their rendered results, and it opens up opportunities to better link between PODs, especially in target formats like HTML. So what about adding a paragraph to perlpodspec (feel free to improve the wording): =item C<XE<lt>topic nameE<gt>> -- an index entry See the brief discussion in L<perlpod/"Formatting Codes">. This code is unusual in that most formatters completely discard this code and its content. Other formatters will render it with invisible codes that can be used in building an index of the current document. +Formatters that support active hyperlinks (like HTML) +should render a hyperlink anchor for C<XE<lt>...E<gt>> +index entries; such for example + + =item open FILEHANDLE + X<open> + +can be linked to by any of + + L</open FILEHANDLE> + L</open> + =item C<ZE<lt>E<gt>> -- a null (zero-effect) formatting code What do you think? Cheers, Marek -----Ursprüngliche Nachricht----- Von: 'Patrice Dumas' [mailto:[email protected]] Gesendet: Samstag, 28. Januar 2012 16:17 An: [email protected] Betreff: Re: pod checker that finds missing internal links? On Sat, Jan 28, 2012 at 03:38:48PM +0100, Marek Rouchal wrote: > podchecker _does_ detect wrong internal links. If you put any of the > following links in the POD you quoted below, podchecker (as of > Pod-Parser-1.38 and higher) will flag it as an error: > > L</"open FILEHANDLE,MODE,EXPRESSION"> > L<"open FILEHANDLE,MODE,EXPRESSION"> > L</open FILEHANDLE,MODE,EXPRESSION> I currently have perl 5.10.1 with Pod-Parser-1.37, I'll retest with something more recent as soon as I have it. > It is true that L</open> will work OK, because perlfunc (at least at > the time when I wrote podchecker) contained many L</function> although > the actual item was > > =item function ARGUMENTS > > and I did not want to flag dozens of errors for those. > In other words: if the =item text matches /(\S+)\s+\S/ Then $1 is also > regarded as a valid reference for L<...> I think that it is wrong, because there won't be an anchor created with that name. Also in all the files I read about Pod, it was nowhere said that the link could be shortened, and instead, the link part of L<...> was always clearly described. > If you think that there should be something changed in podchecker, > then please provide a complete POD example, the podchecker output and > a statement on what should be changed and why. I can only bring the result of the podchecker I have. On =head1 aaa b L</aaa> The result is OK. But the corresponding HTML generated by pod2html is <h1><a name="aaa_b">aaa b</a></h1> <p><a href="#aaa">aaa</a></p> I think that podchecker should tel something here. Also Pod::Simple should show an error too, in my opinion. -- Pat
