At 11:00 AM 2001-08-20 -0400, Ronald J Kimball wrote:
>I agree with Philip, that paragraph-based parsing should *not* be removed.
>The problem of non-empty blank lines is not a reason remove paragraph-based
>parsing; just declare non-empty blank lines to be the same as empty blank
>lines.
First off, when did Philip (Newton?) say that [this kind of]
paragraph-based parsing should be removed? I'd like to see his arguments.
(I do see his message that asks "Does that mean that the following will be
misparsed?[...]" but that was just a question (answered: "no").)
So that I can make sure that we're talking about the same thing: What I
think we're arguing here is just whether or a =foo that starts a pod
section has to be preceded by a blank/empty line, and also whether a =cut
that ends a pod section has to be followed by a blank/empty line.
Correct me if you have something else in mind.
>> mean authors won't have to keep using the absurd formatting as in:
>> "Whatever can't be done with LE<lt>LWP::Simple|LWP::Simple> should be
>> done with LE<lt>LWP::UserAgent|LWP::UserAgent>."
>
>Since the above conventions are just a recommendation (and not even a
>"processors should...", I don't think this keeps authors from having to use
>that absurd formatting. Speaking for myself, if parsers are still allowed
>to expand L<LWP::Simple> as "the LWP::Simple manpage", then I will still
>write L<LWP::Simple|LWP::Simple> (and still hate having to do it).
I agree. I was feeling benificent in permitting different ways to generate
implicated link text (i.e., in the case where there was no L<text|...>, but
on reflection I've come to think that such variance is annoying in the
extreme, and serves no useful purpose.
So I will don the iron fist and make this a requirement:
Processors MUST treat L<LWP::Simple> as if it were L<LWP::Simple|LWP::Simple>.
(Violators will be thrown down a well!!)
So while I'm imposing diktat, I have to come up with the One True Rendering
for the other kinds of L<...>. How about:
Processors MUST treat L</"Functions and Methods"> as if it were L<Functions
and Methods|/"Functions and Methods">
Processors MUST treat L<perlwhatever/"Everything You Ever Wanted To Know
About The Stuff"> as if it were...
and there I'm feeling a bit ambivalent.
For the implicated text there, I'm not sure which I like best:
* Things::Stuff::Guh's section on Everything You Ever Wanted To Know About
The Stuff
* Things::Stuff::Guh's section on "Everything You Ever Wanted To Know About
The Stuff"
* "Everything You Ever Wanted To Know About The Stuff" in Things::Stuff::Guh
>> The text in the "=item [text]" paragraph should not match
>> C<m/^=item\s+\d+\.?\s*$/> or C<m/^=item\s+\*\s*$/>, nor should it
>> match just C<m/^=item\s*$>.
>
>The third regex is redundant with the second. :)
Is it?
C<m/^=item\s+\*\s*$/> matches "=item *", "=item * ", etc.
C<m/^=item\s*$> matches "=item", "=item ", etc.
>> =item *
>>
>> Some parsers may also support an additional kind of "=over"
>> ... "=back" region: one with no "=item" paragraphs, but I<only>
>> ordinary/verbatim paragraphs, and possibly also some nested "=over"
>> ... "=back" regions, "=for..." paragraphs, and "=begin"..."=end"
>> regions. Such an itemless "=over" ... "=back" region in pod is
>> equivalent in meaning to an "<blockquote>...</blockquote>" element in
>> HTML.
>
>This contradicts the rewritten perlpod.pod, which states as a basic rule
>for using =item; "Use at least one inside an =over/=back block."
Yes, I kept vacillating on that as I was writing it. I'm now tempted to
come down on the side of requiring support for =itemless =over, and to
change perlpod specifically. Since =over is so polymorphous already (and
since this is a logical extension of current meanings), I can't think of
this new form introducing any new problems. It merely makes a thing that
used to be an error (for most existing processors, at least), into
something not an error. Moreover, I can't think of any target format that
can't support something like what I have in mind (namely like a blockquote
in HTML).
--
Sean M. Burke [EMAIL PROTECTED] http://www.spinn.net/~sburke/
