On Sun, Jul 31, 2011 at 05:34:22PM -0400, Rocco Caputo wrote:

> Cc: [email protected] ... trying to segue the discussion into that list.

To that same end, I've removed p5p from this reply.

> 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.
> 

I can definitely see the usefulness of a link that leads to all the indexed
entries for a particular term.  However, I'm not convinced this should
replace the current behavior for L<>.  There's a difference between
something that IS foo, and something that is RELATED TO foo.  Sometimes
when using an index I want to follow the multiple branches, but other times
I just want the main entry.

Right now, L<> links to the main entry for a term (specifically, in cases
where X<> is added to the main entry as a convenient link target, as well
as to related entries).  Under your proposal, it would link to all the
entries for a term.  These are both useful; I just hesitate to add the
latter at the cost of the former.

Maybe there's a good way to allow both behaviors?

Ronald

Reply via email to