Skip Menu |

This queue is for tickets about the podlators CPAN distribution.

Report information
The Basics
Id: 43078
Status: resolved
Priority: 0/
Queue: podlators

People
Owner: Nobody in particular
Requestors: ntyni [...] iki.fi
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 2.2.2
Fixed in: 2.3.0



Subject: C<> in the NAME section
Hi Russ, we've got an old bug against the Debian perl package (#304143) about this: % echo "=head1 NAME\n\ntest -- C<test>"|pod2man - | lexgrog -w - -: "test - - *(C`test*(C'" Quoting Colin Watson in the bug: --- Right now, lexgrog is not even close to being able to parse *roff at this level. Even if I were to implement that, other implementations of whatis can't handle this either. For portability, you should avoid constructs like that in the NAME section. --- The one-line patch provided by Rafael Laboissiere doesn't quite work with podlators-2.2.2. The IN_NAME property is reset for the C<> element processing by _handle_element_start(), and so the fix doesn't trigger. Maybe just special-casing "C" like "Para" in _handle_element_start() would work? See the attached patch. -- Niko Tyni ntyni@debian.org
Subject: 0001-Translate-C-to-quotes-in-the-NAME-section.patch
From 3bdae622f7dffb71b69d7bd9da51f078a7b32d04 Mon Sep 17 00:00:00 2001 From: Niko Tyni <ntyni@debian.org> Date: Fri, 6 Feb 2009 15:49:47 +0200 Subject: [PATCH] Translate C<> to quotes in the NAME section As discussed in <http://bugs.debian.org/304143>, markup in the NAME section is non-portable because some whatis generation tools (particularly 'lexgrog') cannot handle it properly. Expanding C<foo> to "foo" fixes the most common problem; possibly other markup should be filtered away altogether. --- lib/Pod/Man.pm | 7 ++++++- t/man.t | 4 ++-- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/lib/Pod/Man.pm b/lib/Pod/Man.pm index 71a4d7a..0b6d0a3 100644 --- a/lib/Pod/Man.pm +++ b/lib/Pod/Man.pm @@ -259,7 +259,7 @@ sub _handle_element_start { # NAME heading. if ($self->can ("cmd_$method")) { DEBUG > 2 and print "<$element> starts saving a tag\n"; - $$self{IN_NAME} = 0 if ($element ne 'Para'); + $$self{IN_NAME} = 0 if ($element ne 'Para' && $element ne 'C'); # How we're going to format embedded text blocks depends on the tag # and also depends on our parent tags. Thankfully, inside tags that @@ -396,6 +396,11 @@ sub quote_literal { # several places in the following regex. my $index = '(?: \[.*\] | \{.*\} )?'; + # If in NAME section, just return an ascii quoted string, to avoid + # confusing tools like whatis + + return qq{"$_"} if $$self{IN_NAME}; + # Check for things that we don't want to quote, and if we find any of # them, return the string with just a font change and no quoting. m{ diff --git a/t/man.t b/t/man.t index 419cce3..fa22f09 100755 --- a/t/man.t +++ b/t/man.t @@ -83,14 +83,14 @@ __DATA__ ### =head1 NAME -gcc - GNU project C and C++ compiler +gcc - GNU project C<C> and C++ compiler =head1 C++ NOTES Other mentions of C++. ### .SH "NAME" -gcc \- GNU project C and C++ compiler +gcc \- GNU project "C" and C++ compiler .SH "\*(C+ NOTES" .IX Header " NOTES" Other mentions of \*(C+. -- 1.5.6.5
Subject: Re: [rt.cpan.org #43078] C<> in the NAME section
Date: Fri, 06 Feb 2009 09:55:25 -0800
To: bug-podlators [...] rt.cpan.org
From: Russ Allbery <rra [...] stanford.edu>
"ntyni@iki.fi via RT" <bug-podlators@rt.cpan.org> writes: Show quoted text
> we've got an old bug against the Debian perl package (#304143) about > this: > > % echo "=head1 NAME\n\ntest -- C<test>"|pod2man - | lexgrog -w - > -: "test - - *(C`test*(C'" > > Quoting Colin Watson in the bug: > > --- > Right now, lexgrog is not even close to being able to parse > *roff at this level. Even if I were to implement that, other > implementations of whatis can't handle this either. > > For portability, you should avoid constructs like that in the NAME > section. > ---
I agree wholeheartedly with Colin. I don't think this is really a bug in podlators -- it's a bug in the POD page. No markup should be used in the NAME section. I see that the pod2man documentation on how to write a man page isn't explicit about this. I'll change that. That being said, it may be appropriate to work around the bug in the POD page in podlators, since it can be hard to get people to fix things like this. Show quoted text
> The one-line patch provided by Rafael Laboissiere doesn't quite work > with podlators-2.2.2. The IN_NAME property is reset for the C<> element > processing by _handle_element_start(), and so the fix doesn't trigger. > > Maybe just special-casing "C" like "Para" in _handle_element_start() > would work? See the attached patch.
Yes, that looks like a good idea. I'll take a look at this for the next release. Thanks! -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Fri Feb 06 13:08:12 2009, rra@stanford.edu wrote: Show quoted text
> "ntyni@iki.fi via RT" <bug-podlators@rt.cpan.org> writes:
Show quoted text
> > % echo "=head1 NAME\n\ntest -- C<test>"|pod2man - | lexgrog -w - > > -: "test - - *(C`test*(C'"
Show quoted text
> I agree wholeheartedly with Colin. I don't think this is really a bug in > podlators -- it's a bug in the POD page. No markup should be used in the > NAME section.
FWIW, my patch for the problematic POD pages in the Perl core was rejected because the bug is elsewhere. See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2009-03/msg00113.html -- Niko Tyni ntyni@debian.org
Subject: Re: [rt.cpan.org #43078] C<> in the NAME section
Date: Thu, 05 Mar 2009 01:45:28 -0800
To: bug-podlators [...] rt.cpan.org
From: Russ Allbery <rra [...] stanford.edu>
"ntyni@iki.fi via RT" <bug-podlators@rt.cpan.org> writes: Show quoted text
> FWIW, my patch for the problematic POD pages in the Perl core was > rejected because the bug is elsewhere. See > > http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2009-03/msg00113.html
Thanks for the pointer. I replied to that thread. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
In podlators 2.3.0, just released, all formatting done by formatting codes in the NAME section is automatically suppressed.  That should ensure that lexgrog and friends stay happy without requiring people know that formatting codes in NAME probably won't work.