Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug #98326 for Pod-Checker: Can we make “A non-empty Z<>” a warning and not an error
0 views
Skip to first unread message
Dan Muey
May 22, 2018, 9:30:02 PM5/22/18
to pod-p...@perl.org
Greetings!
Per Karl Williamson’s request[1] before he makes any changes we’d like to run the idea past you all and get your feedback:
http://perldoc.perl.org/perlpodspec.html says about Z<>:
“This code is unusual is that it should have no content. That is, a processor may complain if it sees Z<potatoes> . Whether or not it complains, the potatoes text should ignored.”
Z<potatoes> seems to fit under warnings (i.e. “may complain” not “should explode”) better because it “may not necessarily cause trouble, but indicate mediocre style.”
I have an edge case where I essentially need inline comments in POD for some parser notation (https://rt.cpan.org/Public/Bug/Display.html?id=98322) and the only option ATM is “mediocre style” of hacking Z<>.
Or, if not by default, can we have a way, a flag maybe, to ignore certain errors that we grok and are OK with?
Alternatively, a way to inhibit 'POD ERRORS' section from being rendered as part of the POD (e.g. send it to STDERR).
A fourth option would be to add a specific inline-comment formatter so you could #<potatoes> without error and without hacking Z<>. (it would be like Z<> but barf if it was empty)
After the RT discussion “making non-empty Z<> merely warn” seems OK, we just wanted it to be discussed here first. Thanks!
—
Dan Muey
[1] https://rt.cpan.org/Ticket/Display.html?id=98326#txn-1787110
Per Karl Williamson’s request[1] before he makes any changes we’d like to run the idea past you all and get your feedback:
http://perldoc.perl.org/perlpodspec.html says about Z<>:
“This code is unusual is that it should have no content. That is, a processor may complain if it sees Z<potatoes> . Whether or not it complains, the potatoes text should ignored.”
Z<potatoes> seems to fit under warnings (i.e. “may complain” not “should explode”) better because it “may not necessarily cause trouble, but indicate mediocre style.”
I have an edge case where I essentially need inline comments in POD for some parser notation (https://rt.cpan.org/Public/Bug/Display.html?id=98322) and the only option ATM is “mediocre style” of hacking Z<>.
Or, if not by default, can we have a way, a flag maybe, to ignore certain errors that we grok and are OK with?
Alternatively, a way to inhibit 'POD ERRORS' section from being rendered as part of the POD (e.g. send it to STDERR).
A fourth option would be to add a specific inline-comment formatter so you could #<potatoes> without error and without hacking Z<>. (it would be like Z<> but barf if it was empty)
After the RT discussion “making non-empty Z<> merely warn” seems OK, we just wanted it to be discussed here first. Thanks!
—
Dan Muey
[1] https://rt.cpan.org/Ticket/Display.html?id=98326#txn-1787110
Dan Muey
May 23, 2018, 3:45:03 PM5/23/18
to pod-p...@perl.org, Karl Williamson
> "$parser->complain_stderr( SOMEVALUE )"
> If you set this attribute to a true value, it will send reports of
> * parsing errors to STDERR. By default, this attribute's value is false,
> * meaning that no output is sent to STDERR.
>
> * Setting "complain_stderr" also sets "no_errata_section".
>
> Please try that and see if it is sufficient to solve your issue
Thanks Karl, unfortunately it won’t because we still want errors to be reported (our lint tests check for those), I just need Z<potatoes> to not be an error.
0 new messages