Markup: README.pod symlink to Perl module renders incorrectly

Created on 23 Jan 2019  Â·  8Comments  Â·  Source: github/markup

Opening a new issue in an attempt to shine some light on my last comment in #1158 and the behaviour observed rendering the README.pod here. I have a mixture of private repositories using the same technique that have a mix of success and failure in displaying the expected result and a minimal example of success here

The symlinks are detected as POD as reported here.

Running locally github-markup, pod2html converts as expected:

$ git rev-parse --short HEAD
8f436ff
$ bundle show | grep linguist
  * github-linguist (7.1.3)
$ bundle exec bin/github-markup ../applify/README.pod | head
<h1 id="NAME">NAME</h1>

<p>Applify - Write object oriented scripts with ease</p>

<h1 id="VERSION">VERSION</h1>

<p>0.15</p>

<h1 id="DESCRIPTION">DESCRIPTION</h1>
$ perl -v | head -n2 | tail -n1
This is perl 5, version 26, subversion 2 (v5.26.2) built for darwin-thread-multi-2level

I did some sanity checking in linguist with additional tests, they all passed.

Most helpful comment

I did some sanity checking in linguist with additional tests, they all passed.

Travis disagreed, but has since been convinced.

Investigating further in the simple repository listed above it is difficult to explain the results of the following three:

Could pod2html be failing occasionally, for some reason and consequently content is passed through in render:
https://github.com/github/markup/blob/de903b8c5abb1ec46a750350560ad7f1888bee30/lib/github/markup/command_implementation.rb#L25-L29

All 8 comments

I did some sanity checking in linguist with additional tests, they all passed.

Travis disagreed, but has since been convinced.

Investigating further in the simple repository listed above it is difficult to explain the results of the following three:

Could pod2html be failing occasionally, for some reason and consequently content is passed through in render:
https://github.com/github/markup/blob/de903b8c5abb1ec46a750350560ad7f1888bee30/lib/github/markup/command_implementation.rb#L25-L29

I've also experienced this issue.

With no changes by me, my repos have gone from looking like this:

screen shot 2019-02-19 at 9 58 31 am

to looking like this:

screen shot 2019-02-19 at 9 58 47 am

This is also affecting my repos. At first I thought it might be a result of the age of the code, but I ran it through github-markup and the results were fine. This is really frustrating...

I've been trying to narrow this down to the smallest valid test case I can write and this is the best I've come up with so far.

This will render correctly:

=encoding UTF-8

=head1 NAME

=head1 FOO

This won't:

=encoding UTF-8

=head1 NAMD

=head1 FOO

I can't explain it.

Having exact same issue with symlinks to PODs, it works in one case, it doesn't in another.

Can we split it

On Mon, Jul 6, 2020, 5:43 PM Anselmo Canfora notifications@github.com
wrote:

Having exact same issue with symlinks to PODs, it works in one case, it
doesn't in another.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/github/markup/issues/1253#issuecomment-654480624, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AQFURVOVKR3YVJNM6F6CPQ3R2JARDANCNFSM4GR25FVA
.

Can we split it
…
On Mon, Jul 6, 2020, 5:43 PM Anselmo Canfora @.*> wrote: Having exact same issue with symlinks to PODs, it works in one case, it doesn't in another. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1253 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQFURVOVKR3YVJNM6F6CPQ3R2JARDANCNFSM4GR25FVA .
https://github.com/github/markup/issues/1253#issuecomment-654480624

Here is a rather interesting data point: ap/Catalyst-View-Template@6318f66

I have a README.pod there which is failing to render… but this one doesn’t link to a .pm file. Instead I put the documentation in a separate .pod file and symlinked that – specifically to try and sidestep this bug. It seemed so obvious that this would work that I didn’t even do an experiment to verify before I used it. But it turns out that even this can fail.

Hopefully this is a new clue into the mystery of what is causing this bug… rather than an entirely separate second(ary) bug. Maybe it gives someone who has investigated this bug a lightbulb moment?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

HyoKim picture HyoKim  Â·  5Comments

schmidtw picture schmidtw  Â·  4Comments

zoffixznet picture zoffixznet  Â·  6Comments

kalkin picture kalkin  Â·  3Comments

ghost picture ghost  Â·  7Comments