On Thu, Feb 02, 2012 at 09:24:30PM +0100, Marek Rouchal wrote: > The main reason why I dislike an additional A<> is that since > the existence of POD nobody really needed it - since anchors > for L<> are created by =head and =item. And as Perl stands for > simplicity and efficiency, you certainly don't want to > force people to rewrite all their POD to add A<> markup > WITH THE SAME CONTENT as the =head/=item near it.
No one was proposing that. The proposal is to *optionally* use A<> to create an link target *in addition to* that created by the =head or =item. The trouble with relying on =head/=item to define the link target is that the primary purpose of that text is to be read by the user. If you want to change the text, you have to change all the links as well, possibly in completely separate documents. Letting the POD tools create "short" anchors is a reasonably effective solution for perlfunc, but not very robust in general. > Honestly, I do not see much difference in arguing whether an > index entry should be an anchor or an anchor should be an > index entry. I am trying to think practical, and that is: > we have X<> and L<>, and all the PODs using these around. > And we can add value by specifying that X<> creates _also_ > an anchor for potential L<>s to link against it. Then we > would not break any existing POD and give guidance to existing > or new renderers. > > And I think we heard enough voices saying that we need index > entries, and I understand that as "don't change the semantics > of X<> being an index entry" - which IMHO does not prevent > us from _extending_ its meaning. The key feature of a link target is that it is unique. You cannot have two identical link targets. There is no such restriction on index markers. You could have multiple X<open> tags in a single document. That is why index entries and link targets should be separate entities. Ronald
