On Jul 29, 2011, at 11:55, Ronald J Kimball wrote: > I have concerns too. This patch overloads the meaning of the X<> tag. > > I think it's likely someone would want to say: > > =head2 foo > > Description of foo > > =head2 bar > X<foo> > > Description of bar > > where bar is related to foo, and so would be listed under foo in the index, > but should not be a target for a link to foo. > > > This functionality should be implemented with a new tag, not by adding > a meaning to the X<> tag that conflicts with the existing meaning.
Cc: [email protected] ... trying to segue the discussion into that list. It's legal and encouraged for the same index term to reference multiple points in the broader text. Indexes have always done this. This example from _TeXbook_ links "indexes" to four anchors in the book: indexes, 261-263, 392-394, 423-425, 481 Unfortunately hypertext doesn't support ambiguous link targets. New syntax for anchors doesn't solve this problem. It only pushes renderer-specific concerns into POD where they don't belong. X<foo> can and should become an anchor wherever it's present. L<foo> can and should link to ALL of them. The anchors' actual names are unimportant implementation details, as long as X<> and L<> do the right things. When we read books, we resolve ambiguous references by visiting the index and branching. We often take multiple branches until our curiosities are satisfied. And we benefit from incidental, serendipitous context while we're there. The obvious solution to ambiguous L<foo> is to emulate books. If we know L<foo> is ambiguous, then we already have a list of link targets. Send the reader to that list, and let them branch out from there. A sufficiently advanced renderer could pop up a menu of options on link click, but again, people writing POD shouldn't need new syntax to make it happen. -- Rocco Caputo <[email protected]>
