Re: Bug #98326 for Pod-Checker: Can we make “A no n-empty Z<>” a warning and not an error
[email protected] (Karl Williamson) Mon, 28 May 2018 21:54:26 -0600
| Newsgroups | perl.pod-people |
|---|---|
| Message-ID | <[email protected]> |
On 05/22/2018 07:18 PM, Dan Muey wrote: > Greetings! >=20 > Per Karl Williamson=E2=80=99s request[1] before he makes any changes we= =E2=80=99d like to run the idea past you all and get your feedback: >=20 > http://perldoc.perl.org/perlpodspec.html says about Z<>: >=20 > =E2=80=9CThis code is unusual is that it should have no content. That i= s, a processor may complain if it sees Z<potatoes> . Whether or not it co= mplains, the potatoes text should ignored.=E2=80=9D >=20 > Z<potatoes> seems to fit under warnings (i.e. =E2=80=9Cmay complain=E2=80= =9D not =E2=80=9Cshould explode=E2=80=9D) better because it =E2=80=9Cmay = not necessarily cause trouble, but indicate mediocre style.=E2=80=9D >=20 > 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=3D9= 8322) and the only option ATM is =E2=80=9Cmediocre style=E2=80=9D of hack= ing Z<>. >=20 > Or, if not by default, can we have a way, a flag maybe, to ignore certa= in errors that we grok and are OK with? >=20 > Alternatively, a way to inhibit 'POD ERRORS' section from being rendere= d as part of the POD (e.g. send it to STDERR). >=20 > 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) >=20 > After the RT discussion =E2=80=9Cmaking non-empty Z<> merely warn=E2=80= =9D seems OK, we just wanted it to be discussed here first. Thanks! >=20 > =E2=80=94 > Dan Muey >=20 > [1] https://rt.cpan.org/Ticket/Display.html?id=3D98326#txn-1787110 >=20 It does seem to me that treating this condition as a fatal error is=20 wrong, and likely to be an accident of implementation. Pod::Checker=20 makes all but a very few of the warnings generated by Pod::Simple fatal.=20 Each such is listed as an exception. My guess is that the exceptions=20 were added one by one as needed, and this one just didn't come up. Saying Z<foo bar> as opposed to Z<> makes no difference in the pod that=20 gets generated, so making it fatal just seems wrong. So I think we=20 should accommodate this request, and I intend to issue a PR to do so, if=20 no objections are raised here.