Re: L<...> things, per perlpodspec

Sean M Burke <[EMAIL PROTECTED]> writes: > I think that it's not a bad idea to render > L as > especially for plaintext formats. URLs are a bit of a special case > anyhow. And rendering them with surrounding anglebrackets is more > co

L<...> things, per perlpodspec

At 01:18 2001-11-14 -0800, Russ Allbery wrote: >[...quoting perlpodspec...] >> Pod processors must now treat "text|"-less links as follows: >> >> L => L >> L => L<"section"|/section> >> L => L<"section" in name|name/section> > >This and some of the other text there outlaws ren

Pod::ParseLink

Here's the parser that I wrote, so that people can see what I'm talking about. It's been minimally tested, but not really hammered yet. # Pod::ParseLink -- Parse an L<> formatting code in POD text. # $Id$ # # Copyright 2001 by Russ Allbery <[EMAIL PROTECTED]> # # This program is free software; y

Re: perlpodspec and perlpod rewrite, draft 3 "final"

Tim Jenness <[EMAIL PROTECTED]> writes: > No tree-based parsing involved at all. Is invoking the markup() method > in a link object all that onerous? No, this is the main part that I don't want to do: > } elsif ($seq_command eq 'P') { > # Special markup for Pod::Hyperlink > # Replace

Re: perlpodspec and perlpod rewrite, draft 3 "final"

On 14 Nov 2001, Russ Allbery wrote: > Tim Jenness <[EMAIL PROTECTED]> writes: > > > Russ, Why don't you use Pod::ParseUtils that is already in the core and > > does exactly what you want (although it will need updating to match any > > changes to L<>). I think that releasing a new link parser is

Re: perlpodspec and perlpod rewrite, draft 3 "final"

Tim Jenness <[EMAIL PROTECTED]> writes: > Russ, Why don't you use Pod::ParseUtils that is already in the core and > does exactly what you want (although it will need updating to match any > changes to L<>). I think that releasing a new link parser is sure to > confuse people (and we don't really