Re: Bug #98326 for Pod-Checker: Can we make “A non-empty Z<>” a warning and not an error
On 05/22/2018 07:18 PM, Dan Muey wrote: 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 . Whether or not it complains, the potatoes text should ignored.” Z 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 # 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 It does seem to me that treating this condition as a fatal error is wrong, and likely to be an accident of implementation. Pod::Checker makes all but a very few of the warnings generated by Pod::Simple fatal. Each such is listed as an exception. My guess is that the exceptions were added one by one as needed, and this one just didn't come up. Saying Z as opposed to Z<> makes no difference in the pod that gets generated, so making it fatal just seems wrong. So I think we should accommodate this request, and I intend to issue a PR to do so, if no objections are raised here.
Re: Bug #98326 for Pod-Checker: Can we make “A non-empty Z<>” a warning and not an error
> "$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 to not be an error.
Re: Bug #98326 for Pod-Checker: Can we make “A non-empty Z<>” a warning and not an error
On 05/22/2018 07:18 PM, Dan Muey wrote: 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 . Whether or not it complains, the potatoes text should ignored.” Z 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 # 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 Perhaps this was added after you filed your ticket: "$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
