Skip Menu |

This queue is for tickets about the Parse-RecDescent-FAQ CPAN distribution.

Report information
The Basics
Id: 51868
Status: new
Priority: 0/
Queue: Parse-RecDescent-FAQ

People
Owner: Nobody in particular
Requestors: FWIE [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 6.0.i
Fixed in: (no value)



Subject: [Patch] POD nits
The attached patch fixes some POD, which renders wrong, at least at search.cpan.org.
Subject: pod.patch
diff --git a/FAQ.tt b/FAQ.tt index 51e1830..e5a9335 100755 --- a/FAQ.tt +++ b/FAQ.tt @@ -1238,9 +1238,9 @@ purity (or something), but that is not really the point. =item * Answer by Damian Conway You can get access to the error data by referring to the attribute -C<$thisparser->{errors}> within a rule. +C<< $thisparser->{errors} >> within a rule. -C<$thisparser->{errors}> is a reference to an array of arrays. Each of +C<< $thisparser->{errors} >> is a reference to an array of arrays. Each of the inner arrays has two elements: the error message, and the line number. @@ -1262,7 +1262,7 @@ Note that the line: $thisparser->{errors} = undef; -is doing double duty. By resetting C<$thisparser->{errors}>, it's +is doing double duty. By resetting C<< $thisparser->{errors} >>, it's preventing those annoying error messages from being automagically printed. And by having the value C<undef> as the last value of the action, it's causing the action to fail, which means the second