(After rereading the meandering thread)
I *think* I'm with Sean on this. The current L<foo/item> versus
L<foo/"section"> difference is fragile and obscure (and underused in
the core pods anyway), and somewhat redundant. To refresh people's
memory perlpod says:
L<name> manual page
L<name/ident> item in manual page
L<name/"sec"> section in other manual page
L<"sec"> section in this manual page
(the quotes are optional)
L</"sec"> ditto
Here's Sean's original message:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-04/msg01017.html
My meandering thoughts on this:
As a whole the L<> is woefully underspecified-- defining it to be 100%
on the mark across all the possible (or even the widely used ones)
target languages is hard. Some of the underspecifiedness may, of
course, be intentional (pod trying to be as minimalistic and neutral
as possible). We cannot (and maybe should not, without losing our
target language neutrality) fix all the L<>'s deficiencies.
I see Sean's proposal (unifying L</> and L</""> as a step of gaining
back some of that neutrality.
The conversion of pod to foo has always been a heuristic art: as long
as the pod2foo converters intuit L<foo/bar> to primarily point to the
document-local bar first, and something external bar second, I don't
think there's a great backward compatibility issue. (I can see an
implementation efficiency issue, though: with the L<foo/bar> versus
L<foo/"bar"> distinction one can immediately intuit whether the
reference is document-local or not, and one does not need to process
the whole document first to know which references are local and which
are external.) But then again, people should be primarily using
L</bar> or L<"bar"> anyway to refer locally, right?
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
