At 01:18 2001-11-14 -0800, Russ Allbery wrote: >[...quoting perlpodspec...] >> Pod processors must now treat "text|"-less links as follows: >> >> L<name> => L<name|name> >> L</section> => L<"section"|/section> >> L<name/section> => L<"section" in name|name/section> > >This and some of the other text there outlaws rendering: > > L<http://www.eyrie.org/~eagle/> >as: > <http://www.eyrie.org/~eagle/>
I authoritatively disagree; I don't outlaw that. I think that it's not a bad idea to render L<http://www.eyrie.org/~eagle/> as <http://www.eyrie.org/~eagle/> especially for plaintext formats. URLs are a bit of a special case anyhow. And rendering them with surrounding anglebrackets is more comparable to rendering I<foo> as *foo* (which is another acceptable compromise for formats with limited capabilites), than comparable to prohibited horrors like L<foo/bar> being rendered as "see 'bar' in the 'foo' man page". (Note that I'm neither recommeding nor requiring that everyone go make all L<http://www.eyrie.org/~eagle/>'s render as <http://www.eyrie.org/~eagle/> for all formats. Personally, if I wanted <>'s around all my links, I'd put them there: <L<url:...>>. But if you're already turning I<x> into *x* or _x_ in some output format, well then, implicating the <>'s seems quite acceptable for that format too.) >[...]This is where to say something about L<"Parsing/Formatting"> if we >want to.[...] Interpreting that strictly, that means a link to a document called '"Parsing', subsection 'Formatting"'. If a link to a section called 'Parsing/Formatting' were intended, it should be expressed as L<"ParsingE<sol>Formatting">. or with an equivalent E<sol>, like E<47>, etc. My personal motto for L processing especially is "This crazy (i.e., only as crazy as perlpodspec necessitates), but NO CRAZIER". However, if one wanted to add further DWIMmity beyond what perlpodspec requires, that can always be encouraged as a matter of extra error-tolerance. -- Sean M. Burke [EMAIL PROTECTED] http://www.spinn.net/~sburke/
