Ticket for collecting all POD ERRORS

[raiph]

== If you have you just seen a POD ERRORS message ==

If a github page corresponding to a doc page displays "POD ERRORS", please:

1. Search this issue page for the relevant topic/filename combo (eg Language/unicode_entry.pod or Type/AST.pod).
2. Skip to the last match, if any. If the last comment mentioning the page you're searching for was written more than a day ago and says it's been fixed, or if there's no match at all, then assume you are seeing a new problem and add a new comment to alert us to a new problem. Please paste a link back to the github page containing the error plus the error message from that page. See the first comment added to this issue below for an example.
3. You can still edit the github page despite the error; just click the Pencil icon.

Thanks!

== Closing this issue ==

When we've: A) eliminated all POD ERRORS generated by github's web interface for displaying P6 doc pages; and B) expect them to only rarely re-occur; then we can close this issue.

[raiph]

https://github.com/perl6/doc/blob/master/lib/Language/unicode_entry.pod

=end pod doesn't match =begin table. (Stack: =begin pod; =begin table; =begin table)

[moritz]

Huh? github shows POD errors because it thinks it's Perl 5 Pod, but we are writing Perl 6 pod. The proper action would be to teach github how to recognize and/or render Perl 6 pod, not trying to lower our standards for markup.

[paultcochrane]

+1 for getting GH to render Pod6. The next question is: how does one convince them to implement it?

[moritz]

Presumably by providing a sufficiently fast implement ourselves....

[raiph]

I went with forgiveness > permission to create the ticket and
then had to run, so was unable to explain what I was thinking
at the time, provided below. I apologize if this is just creating
work for you but I think you missed what I was trying to do
and I request enough more of your patience to read on...

I was thinking that a fast enough renderer was not a sure
thing any time soon.

But let's say someone wrote one and PR'd it in a week.

Aiui it has taken github up to a year to apply P6 related
renderer PRs.

But let's say they applied it in a week.

I was thinking there would likely be "Pod errors" instead of
"POD ERRORS" even if we get a Pod renderer PR applied.

Which means we might be back with the problem Paul
mentioned as his rationale for linking to the raw version.

I created issue #55 to address this so Paul could go ahead
and link to the Pod page, not the raw page, without concern
about when an adequately fast renderer could be written and
PR'd and applied by github and about when we would get the
Pod renderer AND content to the point that those contributing
to the doc were never or truly rarely encountering either POD
ERRORS or Pod errors.

Maybe I'm over complicating things. I sometimes do that when
I'm thinking I'm making things easier. I apologize if I am.

Thanks again for your patience, reading this far, and being a
big part of what makes being involved with Perl 6 so rewarding. :)

raiph

On Thu, Feb 26, 2015 at 5:11 PM, Moritz Lenz notifications@github.com
wrote:

Presumably by providing a sufficiently fast implement ourselves....

—
Reply to this email directly or view it on GitHub
#55 (comment).

raiph