Front page | perl.perl5.porters |
Postings from March 2001
Re: pods patched
From:
Ilya Zakharevich
Date:
March 17, 2001 11:59
Subject:
Re: pods patched
Message ID:
20010317145523.A23953@math.ohio-state.edu
On Sat, Mar 17, 2001 at 09:49:13AM -0600, Jarkko Hietaniemi wrote:
> Okay, since we seem to be able to disagree even on two bytes
> ("=over" vs "=over 4"),
Even less: one byte changes:
This module is very unusual as overloaded modules go: it does not
-provide any usual overloaded operators, instead it provides the L<Last
-Resort> operator C<nomethod>. In this example the corresponding
+provide any usual overloaded operators, instead it provides the
+L<Last Resort> operator C<nomethod>. In this example the corresponding
subroutine returns an object which encapsulates operations done over
Note that the only change is a removal of \n inside L<>. As if the
POD parsers do not normalize whitespace inside L<> and X<>.
Of course, many converters have bugs (like pod2man which breaks in the
presense of newlines inside X<>), but we should not base POD on lame
converters. [IIRC, pod2html wouldn't grok even L<function C<bar>>, not
taking about C<func(I<ARGLIST>)>.]
And why the movement of POD from after __END__ to front, when it will
slow-down calculation (see ExtUtils/MM_OS2.pm)?
Ilya
P.S. On the question of normalization: in my experience, there are 3
possible laxitude levels:
a) normalize whitespace s/\s+/ / (oups, what I do does not
support S< > inside links and link targets :-[);
b) Do (a) and remove all markup;
c) Convert (b) to lowercase;
The converters I support (hmm, probably singular is more
appropriate ;-) do all of those: they maintain 3 hashes, and for
each possible link target they put the 3 variants into 3 hashes.
For each link they do (a,b,c), and look for results in these
hashes correspondingly. The first match wins.