do not wrap long non-verbatim lines in perldiag.pod
authorRicardo Signes <rjbs@cpan.org>
Sun, 26 May 2013 23:16:37 +0000 (19:16 -0400)
committerRicardo Signes <rjbs@cpan.org>
Mon, 27 May 2013 02:16:10 +0000 (22:16 -0400)
This is an unfortunate situation.  diagnostics.pm gets its
explanation of an error or warning from perldiag.pod and (basically)
strips out Pod formatting sequences.  That means that if a line is
long because of a Pod sequence, it may be the "right" length for an
80 column terminal with the Pod stripped, even though the source
document will be "too long."  There isn't much of a presentation
layer here, because diagnostics.pm will not attempt to reflow text.

Adding such a layer may be better later, and the benefit to this
reversion is low, but the benefit of the commit itself was also low.
(In fact, this change may have had no value: the long lines about
which our Pod checker complains are in verbatim paragraphs, and this
line is not a verbatim paragraph.)

This regression was reported by Father Chrysostomos:

After 1dcc3c19f1c0:

  $ ./perl -Ilib -Mdiagnostics -e 'warn "Lexing code attempted to stuff non-Latin-1 character into Latin-1 input"'
  Lexing code attempted to stuff non-Latin-1 character into Latin-1 input at -e
    line 1 (#1)
      (F) An extension is attempting to insert text into the current parse (using
      lex_stuff_pvn or similar), but tried to insert a
      character that couldn't be part of the current input.  This is an inherent
      pitfall of the stuffing mechanism, and one of the reasons to avoid it.  Where
      it is necessary to stuff, stuffing only plain ASCII is recommended.

Note the awkward line break.

This commit reverts a change made in 1dcc3c19f1c0.

pod/perldiag.pod

index 9d9786e..e4c4704 100644 (file)
@@ -2691,10 +2691,10 @@ The number of items in a hash can be obtained by doing:
 
 =item Lexing code attempted to stuff non-Latin-1 character into Latin-1 input
 
-(F) An extension is attempting to insert text into the current parse (using
-L<lex_stuff_pvn|perlapi/lex_stuff_pvn> or similar), but tried to insert a
-character that couldn't be part of the current input.  This is an inherent
-pitfall of the stuffing mechanism, and one of the reasons to avoid it.  Where
+(F) An extension is attempting to insert text into the current parse
+(using L<lex_stuff_pvn|perlapi/lex_stuff_pvn> or similar), but tried to insert a character that
+couldn't be part of the current input.  This is an inherent pitfall
+of the stuffing mechanism, and one of the reasons to avoid it.  Where
 it is necessary to stuff, stuffing only plain ASCII is recommended.
 
 =item Lexing code internal error (%s)