On 04/24/2016 11:34 PM, Marek Rouchal wrote:
Does this mean that there is a "find"-like function in Pod::Simple that
replaces Pod::Find? That would be an opportunity to discontinue
Pod::Find along with Pod::Parser...
-Marek
Looking at the man page, it looks like Pod::Simple::Search does a
I stumbled across a bug in Pod::Simple the other day: It does not create
the promised {'raw'} structure element usable by parsers for L<>
constructs if they occur within another formatting code, such as the
fairly common C>.
I figured out a way to fix this, but in doing so I realized that
Pod
On Fri, 29 Apr 2016 13:34:21 -0600
Karl Williamson wrote:
>Nested L<> are illegal. Pretending inner one is X<> so can
> continue looking for other errors.
That would be Z<>
--
Don't stop where the ink does.
Shawn
On 04/29/2016 01:58 PM, Shawn H Corey wrote:
On Fri, 29 Apr 2016 13:34:21 -0600
Karl Williamson wrote:
Nested L<> are illegal. Pretending inner one is X<> so can
continue looking for other errors.
That would be Z<>
That would generate an additional warning that it wasn't empty. The
On Apr 23, 2016, at 9:45 AM, Neil Bowers wrote:
> I talked this through with RJBS, who suggested the order should instead be:
>
> .pod .pm .pl .plx
>
> David, you added the comment to the code that’s mentioned above. Was there a
> reason you added that comment, or were you just commenti
On Apr 29, 2016, at 11:41 AM, Karl Williamson wrote:
> Looking at the man page, it looks like Pod::Simple::Search does a similar
> function as Pod::Find does
Yes, and it has been there since forever.
Best,
David
* "David E. Wheeler" [2016-04-29T16:43:03]
> Anyone object to making Neil a committer and co-maint on Pod-Simple? (I’m
> hoping Neil doesn’t object.) The canonical repository is here:
No objection, and I preemptively overrule Neil's potential objection.
--
rjbs
signature.asc
Description: Digi
On Fri, Apr 29, 2016 at 1:54 PM, Ricardo Signes
wrote:
> * "David E. Wheeler" [2016-04-29T16:43:03]
> > Anyone object to making Neil a committer and co-maint on Pod-Simple? (I’m
> > hoping Neil doesn’t object.) The canonical repository is here:
>
> No objection, and I preemptively overrule Neil'
Karl Williamson writes:
> Rather than aborting parsing at the point where this occurs, I think it
> should continue on, but generate an errors section, like it does for most
> other errors.
This will cause a hard failure in pod2man and pod2text by default, since
they do not generate ERRORS secti
On 04/29/2016 04:33 PM, Russ Allbery wrote:
Karl Williamson writes:
Rather than aborting parsing at the point where this occurs, I think it
should continue on, but generate an errors section, like it does for most
other errors.
This will cause a hard failure in pod2man and pod2text by defaul
Karl Williamson writes:
> I'm not sure I understand what "fail on generation" means. I think it
> might mean just not generate a pod, rather than generate one with an error
> section.
Correct -- it will exit with an error message.
lothlorien:~$ cat > foo.pod
=item foo
Invalid POD.
lothlorien:
11 matches
Mail list logo