Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Pod-Elemental-Transformer-List CPAN distribution.

Report information
The Basics
Id: 84109
Status: rejected
Priority: 0/
Queue: Pod-Elemental-Transformer-List

People
Owner: Nobody in particular
Requestors: ether [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: Pod coverage tests now fail after transformation
When I switched to using :list elements in this commit: https://github.com/karenetheridge/Test-LWP-UserAgent/branches/topic/list_transformer_breaks_pod_coverage my pod coverage tests started to fail. The diff of the weaved pod looks like: @@ -460,16 +464,20 @@ limited to just that object; if called as a class method, the action or data is global. -=item * C<map_response($request_description, $http_response)> +=item * + +C<map_response($request_description, $http_response)> I'm not sure what Test::Pod::Coverage looks for exactly, but this diff seems to be pretty important.
On Wed Mar 20 22:49:32 2013, ETHER wrote: Show quoted text
> I'm not sure what Test::Pod::Coverage looks for exactly, but this diff > seems > to be pretty important.
(maybe this is really a bug with Test::Pod::Coverage? I haven't checked the html, but these files look the same under 'perldoc'.)
I'm calling this a bug in the docs, or something. I don't think the transformer is wrong. "=item * xyz" is weird pod -- rjbs
On 2013-10-12 19:23:27, RJBS wrote: Show quoted text
> I'm calling this a bug in the docs, or something. I don't think the > transformer is wrong. > > "=item * xyz" is weird pod
Weird how? it's what is created by: =begin :list * foo * bar =end :list
I'm reopening this so I don't forget to discuss this more with rjbs.
we discussed this more... - Pod::Coverage is probably buggy here - and it seems that my usage of putting function names into =items is a little unusual (which is why no one else seems to have noticed the coverage issue). therefore this ticket really belongs in the Pod::Coverage queue.