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.