Re: What to do about L<Foo Bar> and L<"Foo Bar">

On 05/29/2018 04:26 AM, Grant McLean wrote:
> On Tue, 2018-05-29 at 15:20 +1000, Ron Savage wrote:
>> On 29/05/18 13:49, Karl Williamson wrote:
>>> The question is what to do?
>>>
>>> 1) We could leave things as they always have been, to let sleeping
>>> dogs
>>> lie.=C2=A0 It's worked for so long that we're not seriously going to
>>> stop
>>> accepting these.
>> This pretends things have not changed when in fact they have, so not
>> my preference.

I don't understand how things have changed.  Please explain how in fact=20
they have.  My belief is that things haven't changed for a long time=20
now, and things continue to work, without complaint.  There are no=20
tickets against Pod::Simple for any cases of it using its heuristics in=20
these situations and getting things wrong.
>>
>>>
>>> 2) Raise the warnings, either on both cases or just the deprecated
>> Raise warnings on deprecated structures, so uses can fix problems, is
>> my choice here.
>=20
> I agree that this *sounds* like the sensible thing to do, but the
> reality is that it will causes tests to fail. =C2=A0The Test::Pod modul=
e is
> used extensively throughout CPAN and it's function is to take any
> errors or warnings in the file under test and turn them into test
> failures. =C2=A0Distributions which passed their tests when uploaded wi=
ll
> suddenly start to fail tests on install.
>=20
> A few years back I added a warning about non-ASCII characters in POD
> without an =3Dencoding declaration - the fallout continues to this day.
> I'm still smarting from being accused of "breaking half of CPAN" :-)

Ah, so you're the one!
:-)

>=20
> I'm not saying don't chose this option, but it's likely some pain will
> ensue.

Core perl development has moved to more of a position that we don't add=20
new warnings  unless there's good evidence that the benefit greatly=20
outweighs the cost of breaking things.  I don't see that here, which is=20
why I brought up the topic, so it could be discussed.

Nor do we deprecate and remove something unless it is causing us hassles=20
extending and maintaining the core, or perhaps causing significant user=20
confusion or problems.

The reluctance to make these kinds of changes is because of past bitter=20
experiences, like Grant's.
>=20
> A number of people wisely pointed out that Test::Pod should only be
> used in author tests and should not be run at install time. =C2=A0Who k=
nows,
> perhaps enough people have since taken that advice and it won't be a
> problem. =C2=A0If not, regularly breaking things in this way is really =
the
> only way to get that message out. =C2=A0Perhaps a doc patch to POD::Tes=
t
> might help.
>=20
>>> 3) Don't raise warnings, but change Pod::Checker to do so, under
>>> the
>>> theory that you won't be using that unless you want to know the
>>> iffy
>>> things.=C2=A0 Maybe make the deprecated come out always, and the
>>> tolerated
>>> only for level 2 warnings.
>> This imposes a burden on users. Tasks: (a) Change to Pod::Checker,
>> to
>> find problems; (b) Fix problems. Not my preference since it's
>> simpler
>> for the end user to find the same problems under (2).
>=20
> I tend to agree. =C2=A0If non-compliant POD is a problem then I'm not s=
ure
> that option 3 is going to solve that problem.

I started this work, and discovered there was a lot of non-compliant=20
POD, even in the perl core.  And since I never heard of problems with=20
this non-compliant POD, is there really a problem.  So my question again=20
comes down to "Is non-compliant POD really a problem?"
>=20
> Regards
> Grant
>=20