Re: Pod::Simple output as POD

[John SJ Anderson]

> On May 7, 2018, at 21:52, Karl Williamson  wrote:
> 
> And I'm running into something that I know I had not previously gotten as far 
> as (which is encouraging), and I'm writing now for counsel.
> 
> What to do about input files that are encoded in some alien encoding, like 
> Japanese 2202?  The Pod::Simple docs say it translates the pod into perl's 
> internal representation.  But should the extracted pod also be in perl's 
> representation, or should it be translated back to the original encoding?  
> The second way would be a way to really extract the pod portions of the 
> original.
> 
> But I'm thinking it should be perl's, so that downstream modules can use it 
> as-is.  But I'm open to other reasoned opinions

I suspect the plea for counsel was more intended for David, but I’ll pipe up 
from the peanut gallery and say, “why not both?” It seems like the ideal thing 
to put under a feature flag. 

Of course, that just changes this decision into “which one should be the 
default and which one should need to be enabled?”, but perhaps thinking about 
it in those terms will make it more clear which has the higher utility value? 

j.

Re: Is Pod::Simple::POD worth pursuing?

[John SJ Anderson]

On Mon, Jan 13, 2014 at 3:10 PM, Karl Williamson
pub...@khwilliamson.com wrote:
 On 06/27/2013 11:41 PM, John SJ Anderson wrote:

 I'm happy to work towards #1, FWIW. I would think getting it into the
 CPAN Pod::Simple would be a necessary first step there.


 I finally got around to starting on this tonight:
 https://github.com/genehack/pod-simple/tree/add-pod-simple-pod

 Feedback is appreciated, especially on the tests (which are not yet
 all passing). I think I've got the first 80% done, and now I'm dealing
 with the second 80% of various irregularities.


 Thanks for starting this.  What are your current plans regarding it?

I ran out of tuits and it's stalled. If somebody else wants to pick it
up, I have no objections to that. Failing that, I'm putting it back on
my active project list -- but it's at the bottom, the list is long,
and the free time is short... 8^)

j.

Re: Is Pod::Simple::POD worth pursuing?

[John SJ Anderson]

 I'm happy to work towards #1, FWIW. I would think getting it into the
 CPAN Pod::Simple would be a necessary first step there.

I finally got around to starting on this tonight:
https://github.com/genehack/pod-simple/tree/add-pod-simple-pod

Feedback is appreciated, especially on the tests (which are not yet
all passing). I think I've got the first 80% done, and now I'm dealing
with the second 80% of various irregularities.

j.

Re: Is Pod::Simple::POD worth pursuing?

[John SJ Anderson]

On Wed, May 22, 2013 at 9:07 AM, Karl Williamson
pub...@khwilliamson.com wrote:
 In order to remove this dependency, one of these things will have to happen:

 1) We put John's new code in core, and podcheck.t uses it.
 2) I steal John's code and put it in podcheck.t
 3) I reimplement what John's code does, for podcheck.t

 I have been trying to avoid #3.

I'm happy to work towards #1, FWIW. I would think getting it into the
CPAN Pod::Simple would be a necessary first step there.

chrs,
john.

Is Pod::Simple::POD worth pursuing?

[John SJ Anderson]

For reasons too long and unrelated to go into (see
https://github.com/CPAN-API/cpan-api/issues/269 for the tail end of
some of it), I spent a couple hours the other night whacking together
a draft version of Pod::Simple::POD. You can see the repo with the
initial work and a very minimal initial test here:
https://github.com/genehack/pod-simple-pod

Before taking this any further, I thought I'd better ask here:

* Is this a worthwhile idea? (The recent How do I get Pod::Simple to
extract pod thread suggests the answer is yes.)
* Should I be working on this as a branch of Pod::Simple with the idea
it could be included there eventually?
* Does anybody else have any other feedback?

thanks,
john.

Re: Is Pod::Simple::POD worth pursuing?

[John SJ Anderson]

On Tue, May 21, 2013 at 7:16 PM, Ricardo Signes
perl@rjbs.manxome.org wrote:
 It's hard to judge this without the context in which you're considering it.
 The GH issue to which you linked is largely context-free.

The context is that MetaCPAN's '/pod' endpoint is currently using
Pod::POM for this purpose (i.e., returning the POD associated with a
given module). Pod::POM does not return the =encoding line from the
POD. Pod::POM also seems to be effectively abandoned, based on its
rt.cpan.org queue and lack of recent releases. Finally, cpan-api
already depends on Pod::Simple::XHTML, so making it possible for
Pod::Simple to do this would eliminate one dependency there as well as
fix bugs caused by the =encoding line being dropped.

Further deep background: I found this bug when I ran 'cpandoc
utf8::all' when utf8::all was not installed. I noticed a POD encoding
error in the output (the utf8::all SYNOPSIS includes some Unicode
glyphs and there was apparently no =encoding line present). I reported
a bug there, discovered that utf8::all _was_ setting an =encoding
properly, chased it back through Pod::Cpandoc, to MetaCPAN/cpan-api,
and finally to Pod::POM -- where I found two open tickets about the
same issue.  Subsequent discussion on #metacpan lead to the suggestion
of implementing something in Pod::Simple. So, here I am, with this
lovely pile of yak hair and the first 80% of Pod::Simple::Pod. (I
agree about the name suggestion, thanks.)

Anyway, hopefully that helps people better understand what I'm trying
to do here, or at least makes somebody smile ruefully.

chrs,
john.