Re: Recent pod
Johan Vromans jvrom...@squirrel.nl writes: Just what we need... more obscure trickery. Why not replace =item * by something friendly like =bullet ? It's an interesting thought, since one can add new POD commands with backward compatibility. I think in retrospect it's clear that the automatic list type detection from the contents of =item wasn't a great idea, and we would have been better off with =bullet, =number, and =desc. Also quite stupid: =over 4 =item 1. First item. =item 1. Another item. =back I think this used to work and now doesn't work in a kind of weird and annoying way. I seem to recall that this was discussed before, but the current state doesn't make sense to me: either auto-number and warn, or take what the user entered verbatim, but taking what the user entered verbatim and then warning is strange. But I probably haven't thought through it. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: Recent pod
On Feb 24, 2013, at 12:57 PM, H.Merijn Brand h.m.br...@xs4all.nl wrote: =head1 TEST =head2 Return values =over 4 =item undef The return value is undefined =item 0 The return value i numerical 0 (OK). =item * Any other value. =back =cut --8--- Now it gives me TWO errors and dies: $ pod2text test.pod TEST Return values undef The return value is undefined test.pod around line 11: Expected text after =item, not a number 0 The return value i numerical 0 (OK). test.pod around line 15: Expected text after =item, not a bullet * Any other value. This was due to this change: https://github.com/theory/pod-simple/commit/5a01eba83824d9f91ecfae302af33fef65a8385c Note that this is a warning, rather than a fatal error, though of course Test::Pod considers warnings to be test failures. In general, I think that this is an improvement, as one should not usually mix =item formats. I can see that your case is completely legitimate, though. You can fix it by wrapping those items in Cs. But this does raise the question as to whether this change is too much. Thoughts? David
Re: Recent pod
David E. Wheeler da...@justatheory.com writes: This was due to this change: https://github.com/theory/pod-simple/commit/5a01eba83824d9f91ecfae302af33fef65a8385c Note that this is a warning, rather than a fatal error, though of course Test::Pod considers warnings to be test failures. In general, I think that this is an improvement, as one should not usually mix =item formats. I can see that your case is completely legitimate, though. You can fix it by wrapping those items in Cs. Better (since it doesn't change the formatting): =item 0Z =item *Z -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: Recent pod
On Feb 25, 2013, at 9:20 AM, Russ Allbery r...@stanford.edu wrote: Better (since it doesn't change the formatting): =item 0Z =item *Z I think S would work, too. David
Re: Recent pod
David E. Wheeler da...@justatheory.com wrote on Mon, 25 Feb 2013 08:53:29 PST: On Feb 24, 2013, at 12:57 PM, H.Merijn Brand h.m.br...@xs4all.nl wrote: =head1 TEST =head2 Return values =over 4 =item undef The return value is undefined =item 0 The return value i numerical 0 (OK). =item * Any other value. =back =cut --8--- Now it gives me TWO errors and dies: $ pod2text test.pod TEST Return values undef The return value is undefined test.pod around line 11: Expected text after =item, not a number 0 The return value i numerical 0 (OK). test.pod around line 15: Expected text after =item, not a bullet * Any other value. This was due to this change: https://github.com/theory/pod-simple/commit/5a01eba83824d9f91ecfae302aSNIP Note that this is a warning, rather than a fatal error, though of courseSNIP In general, I think that this is an improvement, as one should not usualSNIP But this does raise the question as to whether this change is too much. SNIP Would a prefix Z work to trick it? --tom
Re: Recent pod
Russ Allbery r...@stanford.edu wrote on Mon, 25 Feb 2013 09:20:11 PST: David E. Wheeler da...@justatheory.com writes: This was due to this change: https://github.com/theory/pod-simple/commit/5a01eba83824d9f91ecfae30SNIP Note that this is a warning, rather than a fatal error, though of course Test::Pod considers warnings to be test failures. In general, I think that this is an improvement, as one should not usually mix =item formats. I can see that your case is completely legitimate, though. You can fix it by wrapping those items in Cs. Better (since it doesn't change the formatting): =item 0Z =item *Z I hate not waiting till I've digested the whole thread before giving the same anwwer as was already provided. :) --tom
Re: Recent pod
On Feb 25, 2013, at 9:36 AM, Allison Randal alli...@perl.org wrote:
Those are all pretty weird hacks, and make for ugly Pod.
I find most Pod ugly, anyway. But I use C all the time in such situations.
Can the level
of strictness on =item checking be made configurable? Like, in
_ponder_paragraph_buffer, check !$self-{'allow_mixed_items'} before
whining?
I suppose someone could make that change, but then would Test::Pod have to be
updated to pass through that configuration, as well?
Best,
David
Re: Recent pod
David E. Wheeler da...@justatheory.com writes: On Feb 25, 2013, at 9:20 AM, Russ Allbery r...@stanford.edu wrote: Better (since it doesn't change the formatting): =item 0Z =item *Z I think S would work, too. Just what we need... more obscure trickery. Why not replace =item * by something friendly like =bullet ? Also quite stupid: =over 4 =item 1. First item. =item 1. Another item. =back Computers are very good at numbering list items. -- Johan
