Different rendering of `C<>` formatting code.

[van-de-bugger]

Hi, please consider a test:

$ cat ./test.pl 
#!/usr/bin/perl

use strict;
use warnings;
use utf8::all;

use Pod::Text;

print( $Pod::Text::VERSION, "\n" );

my $parser = Pod::Text->new (sentence => 1, width => 78);
$parser->output_fh( \*STDOUT );
$parser->parse_string_document( '
=encoding UTF-8

case 1: ...the C<--columns $COLUMMNS> option...

case 2: ...the C<--columns
$COLUMMNS> option...

=cut
' );

$ ./test.pl 
v6.0.2
    case 1: ...the "--columns $COLUMMNS" option...

    case 2: ...the --columns $COLUMMNS option...

Note: The first case is rendered with quotes (as expected), but the second case is rendered without quotes (this is not expected).

All the difference between case 1 and case 2 is just a line break inside C<> formatting code. It can easily occur if someone edits the POD source and reformats POD paragraphs. Fragment C<...> can easily occur either in a single line, or be splitted between two (or even more) lines. Such minor detail should not affect the result.

[rra]

The bug here only triggered when the part on a line by itself was a string that would not normally be quoted due to guesswork, such as a variable reference ($COLUMNS). It was a bug in the anchoring of the regex. Should be fixed in the next release. Thanks for the report!