docs/BugLog.html

   1 <?xml version="1.0" ?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml">
   4 <head>
   5 <title></title>
   6 <meta http-equiv="content-type" content="text/html; charset=utf-8" />
   7 <link rev="made" href="mailto:root@localhost" />
   8 </head>
   9
  10 <body>
  11
  12
  13
  14 <ul id="index">
  15   <li><a href="#Issues-fixed-after-release-20211029">Issues fixed after release 20211029</a></li>
  16   <li><a href="#Issues-fixed-after-release-20210625">Issues fixed after release 20210625</a></li>
  17   <li><a href="#Issues-fixed-after-release-20210402">Issues fixed after release 20210402</a></li>
  18   <li><a href="#Issues-fixed-after-release-20210111">Issues fixed after release 20210111</a></li>
  19   <li><a href="#Issues-fixed-after-release-20201207">Issues fixed after release 20201207</a></li>
  20   <li><a href="#Issues-fixed-after-release-20201202">Issues fixed after release 20201202</a></li>
  21   <li><a href="#Issues-fixed-after-release-20201001">Issues fixed after release 20201001</a></li>
  22   <li><a href="#Issues-fixed-after-release-20200907">Issues fixed after release 20200907</a></li>
  23   <li><a href="#Open-Issues">Open Issues</a></li>
  24 </ul>
  25
  26 <h1 id="Issues-fixed-after-release-20211029">Issues fixed after release 20211029</h1>
  27
  28 <dl>
  29
  30 <dt id="Fix-tokenization-issue-c109"><b>Fix tokenization issue c109</b></dt>
  31 <dd>
  32
  33 <p>Automated random testing produced an error tokenizing the following code fragment:</p>
  34
  35 <pre><code>    s s(..)(.)sss
  36     ;</code></pre>
  37
  38 <p>This is equivalent to &#39;s/(..)(.)//s&#39; with &#39;s&#39; as the delimiter instead of &#39;/&#39;. It was tokenized correctly except when the final &#39;s&#39; was followed by a newline, as in the example. When the delimiter is a letter rather than a punctuation character, perltidy exercises some seldom-used code which had an off-by-one loop limit. This has been fixed.</p>
  39
  40 <p>12 Nov 2021.</p>
  41
  42 </dd>
  43 <dt id="Fix-tokenization-of-issue-c106"><b>Fix tokenization of $$^, issue c106</b></dt>
  44 <dd>
  45
  46 <p>Automated random testing produced an error tokenizing the following fragment:</p>
  47
  48 <pre><code>   my$seed=$$^$^T;</code></pre>
  49
  50 <p>The first ^ should have been tokenized as the bitwise xor operator but was not. This is fixed with this update.</p>
  51
  52 <p>8 Nov 2021</p>
  53
  54 </dd>
  55 <dt id="Fix-coding-error-issue-c104"><b>Fix coding error, issue c104</b></dt>
  56 <dd>
  57
  58 <p>Automated random testing produced an error with something like the following input line taken from an obfuscated perl script:</p>
  59
  60 <pre><code>    open(IN, $ 0);</code></pre>
  61
  62 <p>The &#39;0&#39; was missing in the output:</p>
  63
  64 <pre><code>    open( IN, $ );</code></pre>
  65
  66 <p>The tokenization was correct, but a line of code in the formatter which removes the space between the &#39;$&#39; and the &#39;0&#39; should have used a &#39;defined&#39; when doing a check:</p>
  67
  68 <pre><code>    $token .= $word if ($word);             # OLD: error</code></pre>
  69
  70 <p>This if test fails on &#39;0&#39;. The corrected line is</p>
  71
  72 <pre><code>    $token .= $word if ( defined($word) );  # NEW: fixes c104</code></pre>
  73
  74 <p>This fixes the problem and gives the correct formatted result</p>
  75
  76 <pre><code>    open( IN, $0 );</code></pre>
  77
  78 <p>8 Nov 2021.</p>
  79
  80 </dd>
  81 <dt id="Fix-undefined-variable-reference-c102"><b>Fix undefined variable reference, c102</b></dt>
  82 <dd>
  83
  84 <p>Random testing produced an undefined variable reference for the following input</p>
  85
  86 <pre><code>    make_sorter ( sort_sha =&gt; sub {sha512 ( $_} );
  87     make_sorter ( sort_ids =&gt; sub {/^ID:(\d+)/} );</code></pre>
  88
  89 <p>when formatted with the following input parameters:</p>
  90
  91 <pre><code>    --space-function-paren
  92     --maximum-line-length=26
  93     --noadd-newlines</code></pre>
  94
  95 <p>Notice that the input script has a peculiar syntax error - the last two closing tokens of the first line are transposed. (Ironically, this snippet is taken from code which accompanied the book Perl Best Practices). The perltidy tokenizer caught the syntax error, but the formatter touched an undefined variable while attempting to do the formatting. It would be possible to just skip formatting for errors like this, but it can sometimes help finding bugs to see an attempted formatting. So the formatter coding has been corrected to avoid the undefined variable reference.</p>
  96
  97 <p>This fixes issue c102.</p>
  98
  99 <p>5 Nov 2021.</p>
 100
 101 </dd>
 102 <dt id="Some-blocks-with-side-comments-exceed-line-length"><b>Some blocks with side comments exceed line length</b></dt>
 103 <dd>
 104
 105 <p>In some rare cases, one-line blocks with side comments were exceeding the line length limit. These usually had a semicolon between the closing block brace and the side comment. For example:</p>
 106
 107 <pre><code>        my $size
 108             = do { local $^W; -f $local &amp;&amp; -s _ }; # no ALLO if sending data from a pipe</code></pre>
 109
 110 <p>This update breaks the one-line block in an attempt to keep the total length below the line length limit. The result on the above is:</p>
 111
 112 <pre><code>        my $size = do {
 113             local $^W;
 114             -f $local &amp;&amp; -s _;
 115         };    # no ALLO if sending data from a pipe</code></pre>
 116
 117 <p>Note that this break can be prevented by including the flag --ignore-side-comment-lengths or -iscl.</p>
 118
 119 <p>3 Nov 2021.</p>
 120
 121 </dd>
 122 </dl>
 123
 124 <h1 id="Issues-fixed-after-release-20210625">Issues fixed after release 20210625</h1>
 125
 126 <dl>
 127
 128 <dt id="Fix-c090-inconsistent-warning-messages-for-deprecated-syntax"><b>Fix c090, inconsistent warning messages for deprecated syntax</b></dt>
 129 <dd>
 130
 131 <p>For something like the following snippet, a warning about deprecated syntax was either going into the error file or the log file, depending on formatting. This has been fixed.</p>
 132
 133 <pre><code>   do $roff ( &amp;verify($tpage) );</code></pre>
 134
 135 <p>20 Oct 2021, 72e4bb1.</p>
 136
 137 </dd>
 138 <dt id="Fix-c091-incorrect-closing-side-comment"><b>Fix c091, incorrect closing side comment</b></dt>
 139 <dd>
 140
 141 <p>An error was discovered and corrected in the behavior of the --closing-side-comment (-csc) flag when only subs were being marked with the setting -cscl=&#39;sub&#39;. The problem was that in rare cases a closing paren could be marked with &#39;## end&#39;. The cause of the problem is that the pattern matching regex which was generated for this case happens to match an empty string, and it could happen that certain parens had empty strings as block names. This was fixed in two ways. First, the regex was fixed so that it cannot match an empty string. Second, a test for an empty string was added.</p>
 142
 143 <p>20 Oct 2021, aa1a019.</p>
 144
 145 </dd>
 146 <dt id="Issue-c089-improve-vertical-alignment-for-lists-without-parens"><b>Issue c089, improve vertical alignment for lists without parens</b></dt>
 147 <dd>
 148
 149 <p>An update was made to improve vertical alignment in situations where parens are omitted around lists. The goal is to make lists without parens align as they would if they were contained in parens. Some examples:</p>
 150
 151 <pre><code>    # OLD, no parens, no alignment:
 152     glVertex3d $cx + $s * $xs, $cy, $z;
 153     glVertex3d $cx, $cy + $s * $ys, $z;
 154     glVertex3d $cx - $s * $xs, $cy, $z;
 155     glVertex3d $cx, $cy - $s * $ys, $z;
 156
 157     # OLD, with parens and aligned:
 158     glVertex3d( $cx + $s * $xs, $cy,            $z );
 159     glVertex3d( $cx,            $cy + $s * $ys, $z );
 160     glVertex3d( $cx - $s * $xs, $cy,            $z );
 161     glVertex3d( $cx,            $cy - $s * $ys, $z );
 162
 163     # NEW, no parens but aligned
 164     glVertex3d $cx + $s * $xs, $cy,            $z;
 165     glVertex3d $cx,            $cy + $s * $ys, $z;
 166     glVertex3d $cx - $s * $xs, $cy,            $z;
 167     glVertex3d $cx,            $cy - $s * $ys, $z;
 168
 169     # OLD
 170     mkTextConfig $c, $x, $y, -anchor =&gt; &#39;se&#39;, $color;
 171     mkTextConfig $c, $x + 30, $y, -anchor =&gt; &#39;s&#39;,  $color;
 172     mkTextConfig $c, $x + 60, $y, -anchor =&gt; &#39;sw&#39;, $color;
 173     mkTextConfig $c, $x, $y + 30, -anchor =&gt; &#39;e&#39;, $color;
 174
 175     # NEW
 176     mkTextConfig $c, $x,      $y,      -anchor =&gt; &#39;se&#39;, $color;
 177     mkTextConfig $c, $x + 30, $y,      -anchor =&gt; &#39;s&#39;,  $color;
 178     mkTextConfig $c, $x + 60, $y,      -anchor =&gt; &#39;sw&#39;, $color;
 179     mkTextConfig $c, $x,      $y + 30, -anchor =&gt; &#39;e&#39;,  $color;
 180
 181     # OLD
 182     permute_test [ &#39;a&#39;, &#39;b&#39;, &#39;c&#39; ],   &#39;/&#39;, &#39;/&#39;, [ &#39;a&#39;, &#39;b&#39;, &#39;c&#39; ];
 183     permute_test [ &#39;a,&#39;, &#39;b&#39;, &#39;c,&#39; ], &#39;/&#39;, &#39;/&#39;, [ &#39;a,&#39;, &#39;b&#39;, &#39;c,&#39; ];
 184     permute_test [ &#39;a&#39;, &#39;,&#39;, &#39;#&#39;, &#39;c&#39; ], &#39;/&#39;, &#39;/&#39;, [ &#39;a&#39;, &#39;,&#39;, &#39;#&#39;, &#39;c&#39; ];
 185     permute_test [ &#39;f_oo&#39;, &#39;b_ar&#39; ], &#39;/&#39;, &#39;/&#39;, [ &#39;f_oo&#39;, &#39;b_ar&#39; ];
 186
 187     # NEW
 188     permute_test [ &#39;a&#39;, &#39;b&#39;, &#39;c&#39; ],      &#39;/&#39;, &#39;/&#39;, [ &#39;a&#39;, &#39;b&#39;, &#39;c&#39; ];
 189     permute_test [ &#39;a,&#39;, &#39;b&#39;, &#39;c,&#39; ],    &#39;/&#39;, &#39;/&#39;, [ &#39;a,&#39;, &#39;b&#39;, &#39;c,&#39; ];
 190     permute_test [ &#39;a&#39;, &#39;,&#39;, &#39;#&#39;, &#39;c&#39; ], &#39;/&#39;, &#39;/&#39;, [ &#39;a&#39;, &#39;,&#39;, &#39;#&#39;, &#39;c&#39; ];
 191     permute_test [ &#39;f_oo&#39;, &#39;b_ar&#39; ],     &#39;/&#39;, &#39;/&#39;, [ &#39;f_oo&#39;, &#39;b_ar&#39; ];
 192
 193     # OLD:
 194     is $thingy, &quot;fee&quot;,           &quot;source filters apply to evalbytten strings&quot;;
 195     is &quot;foo&quot;,   $unfiltered_foo, &#39;filters leak not out of byte evals&#39;;
 196     is $av-&gt;[2], &quot;NAME:my_xop&quot;,          &quot;OP_NAME returns registered name&quot;;
 197     is $av-&gt;[3], &quot;DESC:XOP for testing&quot;, &quot;OP_DESC returns registered desc&quot;;
 198     is $av-&gt;[4], &quot;CLASS:$OA_UNOP&quot;,       &quot;OP_CLASS returns registered class&quot;;
 199     is scalar @$av, 7, &quot;registered peep called&quot;;
 200     is $av-&gt;[5], &quot;peep:$unop&quot;, &quot;...with correct &#39;o&#39; param&quot;;
 201     is $av-&gt;[6], &quot;oldop:$kid&quot;, &quot;...and correct &#39;oldop&#39; param&quot;;
 202
 203     # NEW
 204     is $av-&gt;[2],    &quot;NAME:my_xop&quot;,          &quot;OP_NAME returns registered name&quot;;
 205     is $av-&gt;[3],    &quot;DESC:XOP for testing&quot;, &quot;OP_DESC returns registered desc&quot;;
 206     is $av-&gt;[4],    &quot;CLASS:$OA_UNOP&quot;,       &quot;OP_CLASS returns registered class&quot;;
 207     is scalar @$av, 7,                      &quot;registered peep called&quot;;
 208     is $av-&gt;[5],    &quot;peep:$unop&quot;,           &quot;...with correct &#39;o&#39; param&quot;;
 209     is $av-&gt;[6],    &quot;oldop:$kid&quot;,           &quot;...and correct &#39;oldop&#39; param&quot;;</code></pre>
 210
 211 <p>20 Oct 2021, 1dffec5.</p>
 212
 213 </dd>
 214 <dt id="Issue-c087-breaking-after-anonymous-sub"><b>Issue c087, breaking after anonymous sub</b></dt>
 215 <dd>
 216
 217 <p>This update keeps both of these configurations stable for all cases except when the -lp option is used. For the -lp option, both become one-line blocks (the second case) to prevents the -lp indentation style from being lost. This update was made to minimize changes to existing formatting.</p>
 218
 219 <pre><code>    $obj = {
 220         foo =&gt; sub { &quot;bar&quot; }
 221     };
 222
 223     $obj = { foo =&gt; sub { &quot;bar&quot; } };</code></pre>
 224
 225 <p>17 Oct 2021, f05e6b5.</p>
 226
 227 </dd>
 228 <dt id="Improve-formatting-of-some-Moose-structures"><b>Improve formatting of some Moose structures</b></dt>
 229 <dd>
 230
 231 <p>In some structures used in Moose coding, some asymmetrical container breaks were being caused by the braces being tokenized as hash braces rather than block braces. This was also causing some unwanted warning messages.</p>
 232
 233 <pre><code>    # OLD
 234     ::is(
 235         ::exception { has &#39;+bar&#39; =&gt; ( default =&gt; sub { 100 } );
 236         },
 237         undef,
 238         &#39;... extended the attribute successfully&#39;
 239     );
 240
 241     # NEW
 242     ::is(
 243         ::exception {
 244             has &#39;+bar&#39; =&gt; ( default =&gt; sub { 100 } );
 245         },
 246         undef,
 247         &#39;... extended the attribute successfully&#39;
 248     );</code></pre>
 249
 250 <p>This fixes issue c074.</p>
 251
 252 <p>12 Oct 2021, 7e873fa.</p>
 253
 254 </dd>
 255 <dt id="Fix-issue-c081--cscw-preventing-deletion-of-closing-side-comments"><b>Fix issue c081, -cscw preventing deletion of closing side comments</b></dt>
 256 <dd>
 257
 258 <p>Random testing revealed a problem in which an old closing side comment was not being deleted when it fell below the interval specified on -csci=n and the -cscw flag was also set.</p>
 259
 260 <p>For example, the following snippet has been formatted with -csc -csci=1. The interval -csci=1 insures that all blocks get side comments:</p>
 261
 262 <pre><code>    if ($x3) {
 263         $zz;
 264         if ($x2) {
 265             if ($x1) {
 266                 ..;
 267             } ## end if ($x1)
 268             $a;
 269             $b;
 270             $c;
 271         } ## end if ($x2)
 272     } ## end if ($x3)</code></pre>
 273
 274 <p>If we then run with -csc -csci=6, the comment ## end if ($x1) will fall below the threshold and be removed (correctly):</p>
 275
 276 <pre><code>    if ($x3) {
 277         $zz;
 278         if ($x2) {
 279             if ($x1) {
 280                 ..;
 281             }
 282             $a;
 283             $b;
 284             $c;
 285         } ## end if ($x2)
 286     } ## end if ($x3)</code></pre>
 287
 288 <p>But if we also add the -cscw flag (warnings) then it was not being removed. This update fixes this problem (issue c081).</p>
 289
 290 <p>2 Oct 2021, 25ef8e8</p>
 291
 292 </dd>
 293 <dt id="Partial-fix-for-issue-git-74-on--lp-at-anonymous-subs"><b>Partial fix for issue git #74 on -lp at anonymous subs</b></dt>
 294 <dd>
 295
 296 <p>In the following snippet, the final one-line anonymous sub is not followed by a comma. This caused the -lp mode to revert to standard indentation mode because a forced line break was being made after the closing sub brace:</p>
 297
 298 <pre><code>    # OLD, perltidy -lp
 299     $got = timethese(
 300         $iterations,
 301         {
 302           Foo =&gt; sub { ++$foo },
 303           Bar =&gt; &#39;++$bar&#39;,
 304           Baz =&gt; sub { ++$baz }
 305         }
 306     );</code></pre>
 307
 308 <p>An update was made to check for and fix this.</p>
 309
 310 <pre><code>    # NEW, perltidy -lp
 311     $got = timethese(
 312                       $iterations,
 313                       {
 314                          Foo =&gt; sub { ++$foo },
 315                          Bar =&gt; &#39;++$bar&#39;,
 316                          Baz =&gt; sub { ++$baz }
 317                       }
 318     );</code></pre>
 319
 320 <p>But note that this only applies to one-line anonymous subs. If an anonymous sub is broken into several lines due to its length or complexity, then these forced line breaks cause indentation to revert to the standard indentation scheme.</p>
 321
 322 <p>22 Sep 2021, 4fd58f7.</p>
 323
 324 </dd>
 325 <dt id="Fix-issues-b1209-related-to--vmll"><b>Fix issues b1209 related to -vmll</b></dt>
 326 <dd>
 327
 328 <p>Testing with random parameters produced a formatting instability related to the -vmll flag. The problem was due to a subtle difference in the definition of nesting depth and indentation level. The vertical aligner was using nesting depth instead of indentation level to compute the maximum line length when -vmll is set. In some rare cases there is a difference. The problem was fixed by passing the maximum line length to the vertical aligner so that the calculation is only done in the formatter. This fixes b1209.</p>
 329
 330 <p>20 Sep 2021, acf1d2d.</p>
 331
 332 </dd>
 333 <dt id="Fix-issue-b1208"><b>Fix issue b1208</b></dt>
 334 <dd>
 335
 336 <p>Testing with random parameters produced a formatting instability which could be triggered when there is a short line length limit and there is a long side comment on the closing brace of a sort/map/grep/eval block. The problem was due to not correctly including the length of the side comment when testing to see if the block could fit on one line. This update fixes issue b1208.</p>
 337
 338 <p>18 Sep 2021, 0af1321.</p>
 339
 340 </dd>
 341 <dt id="Fix-issue-git-73"><b>Fix issue git #73</b></dt>
 342 <dd>
 343
 344 <p>The -nfpva parameter was not working correctly for functions called with pointers. For example</p>
 345
 346 <pre><code>    # OLD: perltidy -sfp -nfpva
 347     $self-&gt;method                ( &#39;parameter_0&#39;, &#39;parameter_1&#39; );
 348     $self-&gt;method_with_long_name ( &#39;parameter_0&#39;, &#39;parameter_1&#39; );
 349
 350     # FIXED: perltidy -sfp -nfpva
 351     $self-&gt;method ( &#39;parameter_0&#39;, &#39;parameter_1&#39; );
 352     $self-&gt;method_with_long_name ( &#39;parameter_0&#39;, &#39;parameter_1&#39; );</code></pre>
 353
 354 <p>The problem had to do with how the pointer tokens &#39;-&gt;&#39; are represented internally and has been fixed.</p>
 355
 356 <p>17 Sep 2021,e3b4a6f.</p>
 357
 358 </dd>
 359 <dt id="Fix-unusual-parsing-error-b1207"><b>Fix unusual parsing error b1207</b></dt>
 360 <dd>
 361
 362 <p>Testing with random parameters produced another instability caused by misparsing an &#39;x&#39; operator after a possible file handle. This is very similar to b1205, but involves a sigil immediately following a times operator.</p>
 363
 364 <p>To illustrate some cases, consider:</p>
 365
 366 <pre><code>    sub x {print &quot;arg is $_[0]\n&quot;}
 367     my $num = 3;
 368     my @list=(1,2,3);
 369     my %hash=(1,2,3,4);
 370     open (my $fh, &quot;&gt;&quot;, &quot;junk.txt&quot;);
 371     print $fh x$num;   # prints a GLOB $num times to STDOUT
 372     print $fh x9;      # prints &#39;x9&#39; to file &#39;junk.txt&#39;
 373     print $fh x@list;  # prints a GLOB 3 times to STDOUT
 374     print $fh x%hash;  # prints a GLOB 2 times to STDOUT</code></pre>
 375
 376 <p>Note in particular the different treatment of the first two print statements.</p>
 377
 378 <p>This update fixes case b1207.</p>
 379
 380 <p>15 Sep 2021, 107586f.</p>
 381
 382 </dd>
 383 <dt id="Fix-formatting-instability-b1206"><b>Fix formatting instability b1206</b></dt>
 384 <dd>
 385
 386 <p>Testing with random parameters produced an instability due welding with a very short line length and large value of -ci. This is similar to issues b1197-b1204 and fixed with a similar method.</p>
 387
 388 <p>14 Sep 2021, 9704cd7.</p>
 389
 390 </dd>
 391 <dt id="Fix-unusual-parsing-error-b1205"><b>Fix unusual parsing error b1205</b></dt>
 392 <dd>
 393
 394 <p>Testing with random parameters produced an instability caused by misparsing an &#39;x&#39; operator after a possible file handle. Testing with Perl showed that an &#39;x&#39; followed by a &#39;(&#39; in this location is always the &#39;times&#39; operator and never a call to a function &#39;x&#39;. If x is immediately followed by a number it is subject to the usual weird parsing rules at such a location.</p>
 395
 396 <p>To illustrate, consider what these statements do:</p>
 397
 398 <pre><code>    open( my $zz, &quot;&gt;&quot;, &quot;junk.txt&quot; );
 399     sub x { return $_[0] }  # never called
 400     print $zz x(2);    # prints a glob 2 times; not a function call
 401     print $zz x 2;     # prints a glob 2 times
 402     print $zz x2;      # syntax error
 403     print $zz x;       # syntax error
 404     print $zz z;       # prints &#39;z&#39; in file &#39;junk.txt&#39;</code></pre>
 405
 406 <p>This update fixes case b1205.</p>
 407
 408 <p>13 Sep 2021, cfa2515.</p>
 409
 410 </dd>
 411 <dt id="Use-stress_level-to-fix-cases-b1197-b1204"><b>Use stress_level to fix cases b1197-b1204</b></dt>
 412 <dd>
 413
 414 <p>Testing with random input parameters produced a number of cases of unstable formatting. All of these involved some combination of a short maximum line length, a large -ci and -i, and often one or more of -xci -lp and -wn. These parameters can force lines to break at poor locations. All of these cases were fixed by introducing a quantity called the &#39;stress_level&#39;, which is the approximate indentation level at which the line break logic comes under high stress and become unstable. For default parameters the stress level is about 12, but unusual parameter combinations can make it much less, even as low as zero. For code which is at an indentation level greater than this depth, some defensive actions are taken to avoid instability, such as temporarily turning off the -xci flag when the indentation depth exceeds the stress level. Most actual working code will not be influenced by this logic. Actual code which has a very deep indentation level can avoid problems by using a long line length, a short number of indentation spaces, or even the whitespace-cycle parameter.</p>
 415
 416 <p>This update fixes issues b1197 b1198 b1199 b1200 b1201 b1202 b1203 b1204</p>
 417
 418 <p>12 Sep 2021, 0ac771e.</p>
 419
 420 </dd>
 421 <dt id="Fix-unusual-hanging-side-comment-issue-c070"><b>Fix unusual hanging side comment issue, c070</b></dt>
 422 <dd>
 423
 424 <p>This issues can be illustrated with the following input script:</p>
 425
 426 <pre><code>    {
 427         if ($xxx) {
 428           ...
 429         } ## end if ($xxx ...
 430         # b &lt;filename&gt;:&lt;line&gt; [&lt;condition&gt;]
 431     }
 432
 433
 434     # OLD: perltidy -fpsc=21
 435     {
 436         if ($xxx) {
 437             ...;
 438         } ## end if ($xxx ...
 439                         # b &lt;filename&gt;:&lt;line&gt; [&lt;condition&gt;]
 440     }</code></pre>
 441
 442 <p>The comment &#39;# b ..&#39; moved over to the column 21 to the right as if it were a side comment. The reason is that it accidentally got marked as a hanging side comment. It should not have been because the previous side comment was a closing side comment. This update fixes this:</p>
 443
 444 <pre><code>    # NEW: perltidy -fpsc=21
 445     {
 446         if ($xxx) {
 447             ...;
 448         } ## end if ($xxx ...
 449
 450         # b &lt;filename&gt;:&lt;line&gt; [&lt;condition&gt;]
 451     }</code></pre>
 452
 453 <p>This fixes issue c070.</p>
 454
 455 <p>10 Sep 2021, ec6ccf9.</p>
 456
 457 </dd>
 458 <dt id="Fix-parsing-issue-c068"><b>Fix parsing issue c068</b></dt>
 459 <dd>
 460
 461 <p>This issue is illustrated with the following line:</p>
 462
 463 <pre><code>   my $aa = $^ ? &quot;defined&quot; : &quot;not defined&quot;;</code></pre>
 464
 465 <p>If we tell perltidy to remove the space before the &#39;?&#39;, then the output will no longer be a valid script:</p>
 466
 467 <pre><code>   # perltidy -nwls=&#39;?&#39;:
 468    my $aa = $^? &quot;defined&quot; : &quot;not defined&quot;;</code></pre>
 469
 470 <p>The problem is that Perl considers &#39;$^?&#39; to be a special variable. So Rerunning perltidy on this gives an error, and perl also gives an error. This update fixes the problem by preventing a space after anything like &#39;$^&#39; from being removed a new special variable would be created.</p>
 471
 472 <p>This fixes issue c068.</p>
 473
 474 <p>7 Sep 2021, 9bc23d1.</p>
 475
 476 </dd>
 477 <dt id="Fix-parsing-problem-issue-c066"><b>Fix parsing problem issue c066</b></dt>
 478 <dd>
 479
 480 <p>This issue is illustrated with the following line (rt80058):</p>
 481
 482 <pre><code>   my $ok=$^Oeq&quot;linux&quot;;</code></pre>
 483
 484 <p>Running perltidy generated a warning message which is caused by the lack of space before the &#39;eq&#39;. This update fixes the problem.</p>
 485
 486 <p>4 Sep 2021, df79a20.</p>
 487
 488 </dd>
 489 <dt id="Fix-unusual-parsing-problem-issue-c065"><b>Fix unusual parsing problem issue c065</b></dt>
 490 <dd>
 491
 492 <p>Testing produced an unusual parsing problem in perltidy which can be illustrated with the following simple script:</p>
 493
 494 <pre><code>    my $str = &#39;a&#39;x2.2;
 495     print $str,&quot;\n&quot;;</code></pre>
 496
 497 <p>Normally an integer would follow the &#39;x&#39; operator, but Perl seems to accept any valid number and truncates it to an integer. So in this case the number 2.2 is truncated to 2 and the output is &#39;aa&#39;.</p>
 498
 499 <p>But perltidy, with default parameters, formats this as</p>
 500
 501 <pre><code>    my $str = &#39;a&#39; x 2 . 2;
 502     print $str,&quot;\n&quot;;</code></pre>
 503
 504 <p>which prints the result &quot;aa2&quot;. The problem is fixed with this update. With the update, the result is</p>
 505
 506 <pre><code>    my $str = &#39;a&#39; x 2.2;
 507     print $str, &quot;\n&quot;;</code></pre>
 508
 509 <p>which is equivalent to the original script.</p>
 510
 511 <p>This fixes issue c065.</p>
 512
 513 <p>4 Sep 2021, f242f78.</p>
 514
 515 </dd>
 516 <dt id="Fix-formatting-instability-issues-b1195-b1196"><b>Fix formatting instability issues b1195, b1196</b></dt>
 517 <dd>
 518
 519 <p>Testing with random parameters produced two similar cases of unstable formatting which are fixed with this update.</p>
 520
 521 <p>28 Aug 2021, ab9ad39.</p>
 522
 523 </dd>
 524 <dt id="Fix-formatting-instability-issue-b1194"><b>Fix formatting instability issue b1194</b></dt>
 525 <dd>
 526
 527 <p>Testing with random parameters produced a case of unstable formatting which is fixed with this update.</p>
 528
 529 <p>This fixes case b1194, and at the same time it simplifies the logic which handles issues b1183 and b1191.</p>
 530
 531 <p>21 Aug 2021, 62e5b01.</p>
 532
 533 </dd>
 534 <dt id="Fix-some-problems-involving-tabs-characters-case-c062"><b>Fix some problems involving tabs characters, case c062</b></dt>
 535 <dd>
 536
 537 <p>This update fixes some problems found in random testing with tab characters. For example, in the following snippet there is a tab character after &#39;sub&#39;</p>
 538
 539 <pre><code>    do sub      : lvalue {
 540         return;
 541       }</code></pre>
 542
 543 <p>Running perltidy on this repeatedly keep increasing the space between &#39;sub&#39; and &#39;:&#39;</p>
 544
 545 <pre><code>    # OLD: perltidy
 546     do sub       : lvalue {
 547         return;
 548       }
 549
 550     # OLD: perltidy
 551     do sub        : lvalue {
 552         return;
 553       }</code></pre>
 554
 555 <p>etc.</p>
 556
 557 <pre><code>    # NEW: perltidy
 558     do sub : lvalue {
 559         return;
 560       }</code></pre>
 561
 562 <p>Problems like this can occur if string comparisons use &#39; &#39; instead of the regex \s when working on spaces. Several instances of this were located and corrected.</p>
 563
 564 <p>This fixes issue c062.</p>
 565
 566 <p>18 Aug 2021, d86787f.</p>
 567
 568 </dd>
 569 <dt id="Correct-parsing-error-case-c061"><b>Correct parsing error, case c061</b></dt>
 570 <dd>
 571
 572 <p>Testing with random input produced an error condition involving a side comment placed between a sub name and prototype, as in the following snippet:</p>
 573
 574 <pre><code>    sub
 575     witch   # sc
 576     ()   # prototype may be on new line ...
 577     { print &quot;which?\n&quot; }
 578     witch();</code></pre>
 579
 580 <p>The current version of perltidy makes an error:</p>
 581
 582 <pre><code>    # OLD: perltidy
 583     sub witch   # sc ()    # prototype may be on new line ...
 584     { print &quot;which?\n&quot; }
 585     witch();</code></pre>
 586
 587 <p>This update corrects the problem:</p>
 588
 589 <pre><code>    # NEW: perltidy
 590     sub witch    # sc
 591       ()         # prototype may be on new line ...
 592     { print &quot;which?\n&quot; }
 593     witch();</code></pre>
 594
 595 <p>This fixes case c061;</p>
 596
 597 <p>18 Aug 2021, 3bb2b2c.</p>
 598
 599 </dd>
 600 <dt id="Improved-line-break-case-c060"><b>Improved line break, case c060</b></dt>
 601 <dd>
 602
 603 <p>The default formatting produced an undesirable line break at the last &#39;&amp;&amp;&#39; term in the following:</p>
 604
 605 <pre><code>    my $static = grep {
 606              $class       =~ /^$_$/
 607           || $fullname    =~ /^$_$/
 608           || $method_name =~ /^$_$/
 609           &amp;&amp; ( $class eq &#39;main&#39; )
 610     } grep { !m![/\\.]! } $self-&gt;dispatch_to;    # filter PATH</code></pre>
 611
 612 <p>This update corrects this to give</p>
 613
 614 <pre><code>    my $static = grep {
 615              $class       =~ /^$_$/
 616           || $fullname    =~ /^$_$/
 617           || $method_name =~ /^$_$/ &amp;&amp; ( $class eq &#39;main&#39; )
 618     } grep { !m![/\\.]! } $self-&gt;dispatch_to;    # filter PATH</code></pre>
 619
 620 <p>15 Aug 2021, 9d1c8a9.</p>
 621
 622 </dd>
 623 <dt id="Fix-error-check-caused-by--wn--iscl-case-c058"><b>Fix error check caused by -wn -iscl, case c058</b></dt>
 624 <dd>
 625
 626 <p>Testing with random parameters triggered an an internal error check. This was caused by a recent coding change which allowed a weld across a side comment. The problem was in the development version, not in the latest released version, and is fixed with this update. This closes issue c058.</p>
 627
 628 <p>14 Aug 2021, 5a13886.</p>
 629
 630 </dd>
 631 <dt id="Fix-formatting-instability-b1193"><b>Fix formatting instability, b1193</b></dt>
 632 <dd>
 633
 634 <p>Testing with random parameters produced unstable formatting involving parameters which included -lp -sbvtc=1. This update fixes this problem, case b1193.</p>
 635
 636 <p>13 Aug 2021, d4c3425.</p>
 637
 638 </dd>
 639 <dt id="Fix-error-in-tokenizer-issue-c055"><b>Fix error in tokenizer, issue c055</b></dt>
 640 <dd>
 641
 642 <p>The ultimate cause of the undefined variable reference in the previous issue was found to be a typo in the tokenizer. This update finishes fixing issue c055.</p>
 643
 644 <p>10 Aug 2021, 2963db3</p>
 645
 646 </dd>
 647 <dt id="Fix-undefined-variable-reference-in-development-version"><b>Fix undefined variable reference in development version</b></dt>
 648 <dd>
 649
 650 <p>In testing, the following unbalanced snippet caused a reference to an undefined value in the current development version (but not in the current released version).</p>
 651
 652 <pre><code>        if($CPAN::Config-&gt;{term_is_latin}){
 653                 $swhat=~s{([\xC0-\xDF])([\x80-\xBF])}{chr(ord($1)&lt;&lt;6&amp;0xC0|ord($2)&amp;0x3F)}eg;}if($self-&gt;colorize_output){if($CPAN::DEBUG&amp;&amp;$swhat=~/^Debug\(/){
 654                         $ornament=$CPAN::Config-&gt;{colorize_debug}||&quot;black on_cyan&quot;;}</code></pre>
 655
 656 <p>A check has been added to fix this.</p>
 657
 658 <p>10 Aug 2021, a3f9774.</p>
 659
 660 </dd>
 661 <dt id="Fix-formatting-instability-b1192"><b>Fix formatting instability, b1192</b></dt>
 662 <dd>
 663
 664 <p>Testing with random parameters produced unstable formatting with the following snippet when run with some unusual parameters:</p>
 665
 666 <pre><code>          @EXPORT =
 667               ( @{$EXPORT_TAGS{standard}}, );</code></pre>
 668
 669 <p>It was also be formatted as</p>
 670
 671 <pre><code>          @EXPORT = (
 672                       @{$EXPORT_TAGS{standard}},
 673           );</code></pre>
 674
 675 <p>The problem was that a list formatting style was turning on and off due to the the needless terminal comma within the parens. A patch was made to ignore commas like this when deciding if list formatting should be used.</p>
 676
 677 <p>This fixes case b1192.</p>
 678
 679 <p>10 Aug 2021, b949215.</p>
 680
 681 </dd>
 682 <dt id="Fix-formatting-instability-b1191"><b>Fix formatting instability, b1191</b></dt>
 683 <dd>
 684
 685 <p>Random testing produced an instability involving an unusual parameter combination and the following input code:</p>
 686
 687 <pre><code>    $_[0]eq$_[1]
 688       or($_[1]=~/^([!~])(.)([\x00-\xff]*)/)
 689       and($1 eq &#39;!&#39;)
 690       ^(eval{($_[2].&quot;::&quot;.$_[0])=~/$2$3/;});</code></pre>
 691
 692 <p>This update fixes case b1191.</p>
 693
 694 <p>9 Aug 2021, 16b4575.</p>
 695
 696 </dd>
 697 <dt id="Fix-error-parsing-sub-attributes-without-spaces-b1190"><b>Fix error parsing sub attributes without spaces, b1190</b></dt>
 698 <dd>
 699
 700 <p>Testing with random parameters produced an instability which was caused by incorrect parsing of a sub attribute list without spaces, as in</p>
 701
 702 <pre><code>        sub:lvalue{&quot;a&quot;}</code></pre>
 703
 704 <p>This update fixes case b1190.</p>
 705
 706 <p>9 Aug 2021, 7008bcc.</p>
 707
 708 </dd>
 709 <dt id="Fix-rare-loss-of-vertical-alignment-in-welded-containers-c053"><b>Fix rare loss of vertical alignment in welded containers, c053</b></dt>
 710 <dd>
 711
 712 <p>This update corrects a rare loss of vertical alignment in welded containers.</p>
 713
 714 <p>To illustrate the issue, the normal formatting of the following snippet is</p>
 715
 716 <pre><code>    # perltidy -sil=1
 717     ( $msg, $defstyle ) = do {
 718             $i == 1 ? ( &quot;First&quot;, &quot;Color&quot; )
 719           : $i == 2 ? ( &quot;Then&quot;, &quot;Rarity&quot; )
 720           :           ( &quot;Then&quot;, &quot;Name&quot; );
 721     };</code></pre>
 722
 723 <p>If it appears within a welded container, the alignment of the last line was being lost:</p>
 724
 725 <pre><code>    # OLD: perltidy -wn -sil=1
 726     { {
 727
 728         ( $msg, $defstyle ) = do {
 729                 $i == 1 ? ( &quot;First&quot;, &quot;Color&quot; )
 730               : $i == 2 ? ( &quot;Then&quot;,  &quot;Rarity&quot; )
 731               : ( &quot;Then&quot;, &quot;Name&quot; );
 732         };
 733     } }</code></pre>
 734
 735 <p>The corrected result is</p>
 736
 737 <pre><code>    # NEW: perltidy -wn -sil=1
 738     { {
 739
 740         ( $msg, $defstyle ) = do {
 741                 $i == 1 ? ( &quot;First&quot;, &quot;Color&quot; )
 742               : $i == 2 ? ( &quot;Then&quot;, &quot;Rarity&quot; )
 743               :           ( &quot;Then&quot;, &quot;Name&quot; );
 744         };
 745     } }</code></pre>
 746
 747 <p>Several other minor vertical alignment issues are fixed with this updated. The problem was that two slightly different measures of the depth of indentation were being compared in the vertical aligner.</p>
 748
 749 <p>This fixes case c053.</p>
 750
 751 <p>8 Aug 2021, 97f02ee.</p>
 752
 753 </dd>
 754 <dt id="Fix-edge-case-of-formatting-instability-b1189"><b>Fix edge case of formatting instability, b1189</b>.</dt>
 755 <dd>
 756
 757 <p>Testing with random parameters produced a case of unstable formatting involving welding with parameter -notrim-qw. The problem was that the -notrim-qw flag converts a qw quote into a quote with fixed leading whitespace. The lines of these types of quotes which have no other code are are output early in the formatting process, since they have a fixed format, so welding does not work. In particular, the closing tokens cannot be welded if they are on a separate line. This also holds for all types of non-qw quotes. So welding can only be done if the first and last lines of a non-qw quote contain other code. A check for this was added.</p>
 758
 759 <p>For example, in the following snippet the terminal &#39;}&#39; is alone on a line:</p>
 760
 761 <pre><code>    is eval(q{
 762         $[ = 3;
 763         BEGIN { my $x = &quot;foo\x{666}&quot;; $x =~ /foo\p{Alnum}/; }
 764         $t[3];
 765     }
 766     ), &quot;a&quot;;</code></pre>
 767
 768 <p># In the previous version this was half-welded: # OLD: perltidy -wn -sil=0</p>
 769
 770 <pre><code>    is eval( q{
 771         $[ = 3;
 772         BEGIN { my $x = &quot;foo\x{666}&quot;; $x =~ /foo\p{Alnum}/; }
 773         $t[3];
 774     }
 775       ),
 776       &quot;a&quot;;</code></pre>
 777
 778 <p>The new check avoids welding in this case, giving</p>
 779
 780 <pre><code>    # NEW: perltidy -wn -sil=0
 781     is eval(
 782         q{
 783         $[ = 3;
 784         BEGIN { my $x = &quot;foo\x{666}&quot;; $x =~ /foo\p{Alnum}/; }
 785         $t[3];
 786     }
 787       ),
 788       &quot;a&quot;;</code></pre>
 789
 790 <p>Welding can still be done if the opening and closing container tokens have other code. For example, welding can be done for the following snippet:</p>
 791
 792 <pre><code>    is eval(q{
 793         $[ = 3;
 794         BEGIN { my $x = &quot;foo\x{666}&quot;; $x =~ /foo\p{Alnum}/; }
 795         $t[3];
 796     }), &quot;a&quot;;</code></pre>
 797
 798 <p>And welding can still be done on all qw quotes unless the -notrim-qw flag is set.</p>
 799
 800 <p>This fixes case b1189.</p>
 801
 802 <p>7 Aug 2021, e9c25f2.</p>
 803
 804 </dd>
 805 <dt id="Fix-edge-cases-of-formatting-instability-b1187-b1188"><b>Fix edge cases of formatting instability, b1187 b1188</b>.</dt>
 806 <dd>
 807
 808 <p>Testing with random parameters produced some cases of instability involving -wn -lp and several other parameters. The mechanism involved an interaction between the formatter and vertical aligner.</p>
 809
 810 <p>This fixes cases b1187 and b1188.</p>
 811
 812 <p>3 Aug 2021, 5be949b.</p>
 813
 814 </dd>
 815 <dt id="Fix-edge-case-of-formatting-instability-b1186"><b>Fix edge case of formatting instability, b1186</b>.</dt>
 816 <dd>
 817
 818 <p>Testing with random parameters produced a case of instability involving parameter -lp -pvt=n and a short maximum line length.</p>
 819
 820 <p>This fixes case b1186.</p>
 821
 822 <p>2 Aug 2021, f3dbee1.</p>
 823
 824 </dd>
 825 <dt id="Fix-edge-case-of-formatting-instability-b1185"><b>Fix edge case of formatting instability, b1185</b>.</dt>
 826 <dd>
 827
 828 <p>Testing with random parameters produced a case of welding instability involving parameters -wn, -vt=2, -lp and a short maximum line length.</p>
 829
 830 <p>This fixes case b1185.</p>
 831
 832 <p>1 Aug 2021, d2ab2b7.</p>
 833
 834 </dd>
 835 <dt id="Fix-edge-case-of-formatting-instability-b1183"><b>Fix edge case of formatting instability, b1183</b>.</dt>
 836 <dd>
 837
 838 <p>Testing with random parameters produced a case of welding instability involving parameters -wn, -vt=n, -lp. This update fixes the problem.</p>
 839
 840 <p>This fixes case b1183.</p>
 841
 842 <p>30 Jul 2021, 055650b.</p>
 843
 844 </dd>
 845 <dt id="Fix-edge-case-of-formatting-instability-b1184"><b>Fix edge case of formatting instability, b1184</b>.</dt>
 846 <dd>
 847
 848 <p>Testing with random parameters produced a case of welding instability involving a tripple weld with parameters -wn, -vt=n, -lp. This update fixes the problem.</p>
 849
 850 <p>This fixes case b1184.</p>
 851
 852 <p>29 Jul 2021, 6dd53fb.</p>
 853
 854 </dd>
 855 <dt id="Fix-edge-case-of-formatting-instability-b1182"><b>Fix edge case of formatting instability, b1182</b>.</dt>
 856 <dd>
 857
 858 <p>Testing with random parameters produced a case of welding instability involving unusual parameters and welding long ternary expressions. This update fixes the problem.</p>
 859
 860 <p>This fixes case b1182.</p>
 861
 862 <p>28 Jul 2021, 01d6c40.</p>
 863
 864 </dd>
 865 <dt id="Fix-edge-case-of-formatting-instability"><b>Fix edge case of formatting instability</b>.</dt>
 866 <dd>
 867
 868 <p>Random testing with random input parameters produced cases of formatting instability involving welding with unusual parameter settings. This update makes a small tolarance adjustment to fix it.</p>
 869
 870 <p>This fixes cases b1180 b1181.</p>
 871
 872 <p>28 Jul 2021, b38ccfc.</p>
 873
 874 </dd>
 875 <dt id="Fix-rare-problem-with-formatting-nested-ternary-statements"><b>Fix rare problem with formatting nested ternary statements</b></dt>
 876 <dd>
 877
 878 <p>This update fixes an extremely rare problem in formatting nested ternary statements, illustrated in the following snippet:</p>
 879
 880 <pre><code>  # OLD: There should be a break before the &#39;?&#39; in line 11 here:
 881   WriteMakefile(
 882       (
 883           $PERL_CORE ? ()
 884           : (
 885               (
 886                   eval { ExtUtils::MakeMaker-&gt;VERSION(6.48) }
 887                   ? ( MIN_PERL_VERSION =&gt; &#39;5.006&#39; )
 888                   : ()
 889               ),
 890               (
 891                   eval { ExtUtils::MakeMaker-&gt;VERSION(6.46) } ? (
 892                       META_MERGE =&gt; {
 893                           #
 894                       }
 895                     )
 896                   : ()
 897               ),
 898           )
 899       ),
 900   );
 901
 902   # NEW: Line 12 correctly begins with a &#39;?&#39;
 903   WriteMakefile(
 904       (
 905           $PERL_CORE ? ()
 906           : (
 907               (
 908                   eval { ExtUtils::MakeMaker-&gt;VERSION(6.48) }
 909                   ? ( MIN_PERL_VERSION =&gt; &#39;5.006&#39; )
 910                   : ()
 911               ),
 912               (
 913                   eval { ExtUtils::MakeMaker-&gt;VERSION(6.46) }
 914                   ? (
 915                       META_MERGE =&gt; {
 916                           #
 917                       }
 918                     )
 919                   : ()
 920               ),
 921           )
 922       ),
 923   );</code></pre>
 924
 925 <p>This fixes issue c050, 63784d8.</p>
 926
 927 <p>22 Jul 2021.</p>
 928
 929 </dd>
 930 <dt id="Fix-conflict-of--bom-and--scp-parameters"><b>Fix conflict of -bom and -scp parameters</b></dt>
 931 <dd>
 932
 933 <p>Automated testing with random parameters produced a case of instability caused by a conflict of parameters -bom and -scp. In the following script the -bom command says to keep the tokens &#39;)-&gt;&#39; on a new line, whereas the -scp command says to stack the closing paren on the previous line.</p>
 934
 935 <pre><code>        $resource = {
 936                 id =&gt; $package-&gt;new_from_mana(
 937                         $result-&gt;{data}
 938                 )-&gt;id
 939         };</code></pre>
 940
 941 <p>The parameters are:</p>
 942
 943 <pre><code>    --break-at-old-method-breakpoints
 944     --indent-columns=8
 945     --maximum-line-length=60
 946     --stack-closing-paren</code></pre>
 947
 948 <p>This caused an instability which was fixed by giving priority to the -bom flag. The stable state is then</p>
 949
 950 <pre><code>        $resource = { id =&gt; $package-&gt;new_from_mana(
 951                         $result-&gt;{data}
 952         )-&gt;id };</code></pre>
 953
 954 <p>This fixes case b1179.</p>
 955
 956 <p>21 Jul 2021, 4ecc078.</p>
 957
 958 </dd>
 959 <dt id="Fix-problems-with--kgb-in-complex-structures"><b>Fix problems with -kgb in complex structures</b></dt>
 960 <dd>
 961
 962 <p>This update fixes two problems involving the -kgb option.</p>
 963
 964 <p>The first problem is that testing with random parameters produced some examples of formatting instabilities involving applying --keyword-group-blanks to complex structures, particularly welded structures. The -kgb parameters work well on simple statements or simple lists, so a check was added to prevent them from working on lists which are more than one level deep. This fixes issues b1177 and b1178 without significantly changing the -kgb functionality.</p>
 965
 966 <p>The second problem is that a terminal blank line could be misplaced if the last statement was a structure. This is illustrated with the following snippet:</p>
 967
 968 <pre><code>    sub new {
 969       my $class = shift;
 970       my $number = shift || croak &quot;What?? No number??\n&quot;;
 971       my $classToGenerate = shift || croak &quot;Need a class to generate, man!\n&quot;;
 972       my $hash = shift; #No carp here, some operators do not need specific stuff
 973       my $self = { _number =&gt; $number,
 974                    _class =&gt; $classToGenerate,
 975                    _hash =&gt; $hash };
 976       bless $self, $class; # And bless it
 977       return $self;
 978     }
 979
 980     # OLD: perltidy -kgb -sil=0 gave
 981     sub new {
 982
 983         my $class           = shift;
 984         my $number          = shift || croak &quot;What?? No number??\n&quot;;
 985         my $classToGenerate = shift || croak &quot;Need a class to generate, man!\n&quot;;
 986         my $hash = shift;   #No carp here, some operators do not need specific stuff
 987         my $self = {
 988             _number =&gt; $number,
 989
 990             _class =&gt; $classToGenerate,
 991             _hash  =&gt; $hash
 992         };
 993         bless $self, $class;    # And bless it
 994         return $self;
 995     }</code></pre>
 996
 997 <p>The blank line which has appeared after the line &#39;_number =&gt;&#39; was intended to go after the closing brace but a line count was off. This has been fixed:</p>
 998
 999 <pre><code>    # NEW: perltidy -kgb -sil=0 gives
1000     sub new {
1001
1002         my $class           = shift;
1003         my $number          = shift || croak &quot;What?? No number??\n&quot;;
1004         my $classToGenerate = shift || croak &quot;Need a class to generate, man!\n&quot;;
1005         my $hash = shift;   #No carp here, some operators do not need specific stuff
1006         my $self = {
1007             _number =&gt; $number,
1008             _class  =&gt; $classToGenerate,
1009             _hash   =&gt; $hash
1010         };
1011
1012         bless $self, $class;    # And bless it
1013         return $self;
1014     }</code></pre>
1015
1016 <p>This fixes issue c048.</p>
1017
1018 <p>19 Jul 2021, 071a3f6.</p>
1019
1020 </dd>
1021 <dt id="Fix-to-keep-from-losing-blank-lines-after-a-code-skipping-section"><b>Fix to keep from losing blank lines after a code-skipping section</b></dt>
1022 <dd>
1023
1024 <p>A problem in the current version of perltidy is that a blank line after the closing code-skipping comment can be lost if there was a blank line before the start of the code skipping section. For example, given the following code:</p>
1025
1026 <pre><code>    $x = 1;
1027
1028     #&lt;&lt;V
1029     % # = ( foo =&gt; &#39;bar&#39;, baz =&gt; &#39;buz&#39; );
1030     print keys(%#), &quot;\n&quot;;
1031     #&gt;&gt;V
1032
1033     @# = ( foo, &#39;bar&#39;, baz, &#39;buz&#39; );
1034     print @#, &quot;\n&quot;;</code></pre>
1035
1036 <p>running perltidy gives:</p>
1037
1038 <pre><code>    $x = 1;
1039
1040     #&lt;&lt;V
1041     % # = ( foo =&gt; &#39;bar&#39;, baz =&gt; &#39;buz&#39; );
1042     print keys(%#), &quot;\n&quot;;
1043     #&gt;&gt;V
1044     @# = ( foo, &#39;bar&#39;, baz, &#39;buz&#39; );
1045     print @#, &quot;\n&quot;;</code></pre>
1046
1047 <p>Notice that the blank line after the closing comment #&gt;&gt;V is missing. What happened is that the formatter is counting blank lines and did not &#39;see&#39; the code skipping section. So the blank after the closing comment looked like the second blank in a row, so it got removed since the default is --maximum-consecutive-blank-lines=1.</p>
1048
1049 <p>This update fixes this by resetting the counter. This fixes case c047. A simple workaround until the next release is to include the parameter</p>
1050
1051 <p>--maximum-consecutive-blank-lines=2, or -mbl=2.</p>
1052
1053 <p>It can be removed after the next release.</p>
1054
1055 <p>18 Jul 2021, 9648e16.</p>
1056
1057 </dd>
1058 <dt id="Fix-possible-welding-instability-in-ternary-after-fat-comma"><b>Fix possible welding instability in ternary after fat comma</b></dt>
1059 <dd>
1060
1061 <p>Random testing produced a case of formatting instability involving welding within a ternary expression following a fat comma:</p>
1062
1063 <pre><code>    if ( $op and $op eq &#39;do_search&#39; ) {
1064         @{$invoices} =
1065           GetInvoices(
1066               shipmentdatefrom =&gt;
1067               $shipmentdatefrom ? output_pref( {
1068                              str =&gt; $shipmentdatefrom,
1069                              dateformat =&gt; &#39;iso&#39;
1070               } )
1071               : undef,
1072               publicationyear =&gt; $publicationyear,
1073           );
1074     }</code></pre>
1075
1076 <p>when the following specific parameters were used</p>
1077
1078 <pre><code>    --extended-continuation-indentation
1079     --line-up-parentheses
1080     --maximum-line-length=38
1081     --variable-maximum-line-length
1082     --weld-nested-containers</code></pre>
1083
1084 <p>This update fixes this issue, case b1174.</p>
1085
1086 <p>18 Jul 2021, 12ae46b.</p>
1087
1088 </dd>
1089 <dt id="Fix-mis-tokenization-before-pointer"><b>Fix mis-tokenization before pointer</b></dt>
1090 <dd>
1091
1092 <p>Random testing produced the following case in which formatting was unstable because the variable &#39;$t&#39; was being mis-tokenized as a possible indirect object.</p>
1093
1094 <pre><code>    --break-before-all-operators
1095     --ignore-old-breakpoints
1096     --maximum-line-length=22
1097     -sil=0
1098
1099     my $json_response
1100       = decode_json $t
1101       -&gt;tx-&gt;res-&gt;content
1102       -&gt;get_body_chunk;</code></pre>
1103
1104 <p>This update fixes cases b1175, b1176.</p>
1105
1106 <p>17 Jul 2021, 4aa1318.</p>
1107
1108 </dd>
1109 <dt id="Fix-to-make--wn-and--bbxx-n-flags-work-together"><b>Fix to make -wn and -bbxx=n flags work together</b></dt>
1110 <dd>
1111
1112 <p>Testing with random parameters produced some cases where the combination of -wn and various -bbxx=n flags were not working together. To illustrate, consider the following script (-sil=1 just means start at 1 indentation level)</p>
1113
1114 <pre><code>    # perltidy -sil=1
1115     $$d{&quot;day_name&quot;} = [
1116         [
1117             &quot;lundi&quot;,    &quot;mardi&quot;,  &quot;mercredi&quot;, &quot;jeudi&quot;,
1118             &quot;vendredi&quot;, &quot;samedi&quot;, &quot;dimanche&quot;
1119         ]
1120     ];</code></pre>
1121
1122 <p>With welding we get:</p>
1123
1124 <pre><code>    # -sil=1 -wn
1125     $$d{&quot;day_name&quot;} = [ [
1126         &quot;lundi&quot;,    &quot;mardi&quot;,  &quot;mercredi&quot;, &quot;jeudi&quot;,
1127         &quot;vendredi&quot;, &quot;samedi&quot;, &quot;dimanche&quot;
1128     ] ];</code></pre>
1129
1130 <p>With -bbsb=3 (--break-before-square-brackets) we get:</p>
1131
1132 <pre><code>    # -sil=1 -bbsb=3
1133     $$d{&quot;day_name&quot;} =
1134       [
1135         [
1136             &quot;lundi&quot;,    &quot;mardi&quot;,  &quot;mercredi&quot;, &quot;jeudi&quot;,
1137             &quot;vendredi&quot;, &quot;samedi&quot;, &quot;dimanche&quot;
1138         ]
1139       ];</code></pre>
1140
1141 <p>So far, so good. But for the combination -bbsb=3 -wn we get</p>
1142
1143 <pre><code>    # OLD: ERROR
1144     # -sil=1 -bbsb=3 -wn
1145     $$d{&quot;day_name&quot;} = [ [
1146         &quot;lundi&quot;,    &quot;mardi&quot;,  &quot;mercredi&quot;, &quot;jeudi&quot;,
1147         &quot;vendredi&quot;, &quot;samedi&quot;, &quot;dimanche&quot;
1148     ] ];</code></pre>
1149
1150 <p>which is incorrect because it ignors the -bbsb flag. The corrected result is</p>
1151
1152 <pre><code>    # NEW: OK
1153     # -sil=1 -bbsb=3 -wn
1154     $$d{&quot;day_name&quot;} =
1155       [ [
1156         &quot;lundi&quot;,    &quot;mardi&quot;,  &quot;mercredi&quot;, &quot;jeudi&quot;,
1157         &quot;vendredi&quot;, &quot;samedi&quot;, &quot;dimanche&quot;
1158       ] ];</code></pre>
1159
1160 <p>This update fixes case b1173. It works for any number of welded containers, and the -bbxxi=n flags also work correctly.</p>
1161
1162 <p>16 Jul 2021, c71f882.</p>
1163
1164 </dd>
1165 <dt id="Fix-problem-with-side-comment-after-pattern"><b>Fix problem with side comment after pattern</b></dt>
1166 <dd>
1167
1168 <p>Testing with randomly placed side comments produced an error illustrated with the following snippet:</p>
1169
1170 <pre><code>    testit
1171     /A (*THEN) X | B (*THEN) C/x#sc#
1172     ,
1173     &quot;Simple (*THEN) test&quot;
1174     ;</code></pre>
1175
1176 <p>If &#39;testit&#39; is an unknown bareword then perltidy has to guess if the &#39;/&#39; is a division or can start a pattern. In this case the side comment caused a bad guess. This is case c044 and is fixed with this update. There are no other known issues with side comments at the present time but testing continues.</p>
1177
1178 <p>13 Jul 2021, 8b36de8.</p>
1179
1180 </dd>
1181 <dt id="Fix-problem-with-side-comment-after-pointer-part-3"><b>Fix problem with side comment after pointer, part 3</b></dt>
1182 <dd>
1183
1184 <p>This update fixes some incorrect tokenization produced by a side comment placed between a pointer and a bareword as in this snippet:</p>
1185
1186 <pre><code>    sub tzoffset {};
1187
1188     ...
1189
1190     my $J
1191     +=
1192     (
1193     $self
1194     -&gt;#sc
1195     tzoffset
1196     / (
1197     24
1198     *
1199     3600
1200     )
1201     );</code></pre>
1202
1203 <p>If a sub declaration for the bareword has been seen, the following &#39;/&#39; was being rejected as an operator. This update fixes this case, which is issue c043.</p>
1204
1205 <p>13 Jul 2021, cab7ed3.</p>
1206
1207 </dd>
1208 <dt id="Avoid-line-breaks-before-a-slash-in-certain-cases"><b>Avoid line breaks before a slash in certain cases</b></dt>
1209 <dd>
1210
1211 <p>This is a modification to the previous update for case c039 which prevents a line break before a &#39;/&#39; character which follows a bareword or possible indirect object. This rule will be only be used to prevent creating new line breaks. Existing line breaks can remain.</p>
1212
1213 <p>11 Jul 2021, 7afee47.</p>
1214
1215 </dd>
1216 <dt id="Fix-error-parsing-sub-attributes-with-side-comment"><b>Fix error parsing sub attributes with side comment</b></dt>
1217 <dd>
1218
1219 <p>Testing with side comments produced an error in the following snippet:</p>
1220
1221 <pre><code>    sub plugh () :#
1222       Ugly(&#39;\(&quot;) : Bad;</code></pre>
1223
1224 <p>This is fixed in this update, case c038.</p>
1225
1226 <p>11 Jul 2021, 80f2a3a.</p>
1227
1228 </dd>
1229 <dt id="Fix-case-b1172-a-failure-to-converge"><b>Fix case b1172, a failure to converge</b></dt>
1230 <dd>
1231
1232 <p>Random testing produced case b1172, a failure to converge with unusual parametrs. This update fixes this case. There are no other known cases of instability at the present time but testing continues.</p>
1233
1234 <p>10 Jul 2021, 47e7f9b.</p>
1235
1236 </dd>
1237 <dt id="Avoid-line-breaks-before-a-slash-in-certain-cases1"><b>Avoid line breaks before a slash in certain cases</b></dt>
1238 <dd>
1239
1240 <p>This update prevents a line break before a &#39;/&#39; character which follows a bareword or possible indirect object. The purpose is reduce the chance of introducing a syntax error in cases where perl is using spaces to distinguish between a division and the start of a pattern.</p>
1241
1242 <p>This fixes case c039.</p>
1243
1244 <p>10 Jul 2021, 461199c.</p>
1245
1246 </dd>
1247 <dt id="Removed-warning-message-if-ending-in-code-skipping-section"><b>Removed warning message if ending in code skipping section</b></dt>
1248 <dd>
1249
1250 <p>In the previous version, a warning was produced if a &#39;code-skipping&#39; opening comment &#39;#&lt;&lt;V&#39; was not followed by a closing comment &#39;#&gt;&gt;V&#39;. But the related &#39;format-skipping&#39; commands do not give a warning if a &#39;#&lt;&lt;&lt;&#39; comment is not ended with a &#39;#&gt;&gt;&gt;&#39; closing comment. In order to be able to smoothly change between these options, it seems best to remove the warning about a missing &#39;#&gt;&gt;V&#39;. There is still a message in the log file about this, so if there is any uncertainty about it, a log file can be saved and consulted.</p>
1251
1252 <p>10 Jul 2021, 461199c.</p>
1253
1254 </dd>
1255 <dt id="Improve-logic-for-distinguishing-a-pattern-vs-a-division"><b>Improve logic for distinguishing a pattern vs a division</b></dt>
1256 <dd>
1257
1258 <p>Testing with side comments produced the following snippet which caused a error due to the side comment on the &#39;/&#39;</p>
1259
1260 <pre><code>    $bond_str
1261     =
1262     VERY_WEAK #sc#
1263     / #sc#
1264     1.05
1265     ;</code></pre>
1266
1267 <p>Several related examples were found in which side comments triggered errors. For example</p>
1268
1269 <pre><code>    ok
1270     /[^\s]+/#sc#
1271     ,
1272     &#39;m/[^\s]/ utf8&#39;
1273     ;</code></pre>
1274
1275 <p>This update fixes these problems, case c040.</p>
1276
1277 <p>9 Jul 2021, ffe4351.</p>
1278
1279 </dd>
1280 <dt id="Fix-problem-caused-by-side-comment-after"><b>Fix problem caused by side comment after ++</b></dt>
1281 <dd>
1282
1283 <p>Testing with side comments produced an incorrect error message for this snippet:</p>
1284
1285 <pre><code>    xxx
1286     ++#
1287     $test,
1288     Internals::SvREADONLY( %$copy) ,
1289     &quot;cloned hash restricted?&quot; ;</code></pre>
1290
1291 <p>The problem was caused by the side comment between the &#39;++&#39; and &#39;$test&#39;. The same problem occurs for &#39;--&#39; instead of &#39;++&#39;. This is fixed with this update, case c042.</p>
1292
1293 <p>8 Jul 2021, 20cc9a0.</p>
1294
1295 </dd>
1296 <dt id="Fix-problem-caused-by-side-comment-after-pointer-part-2"><b>Fix problem caused by side comment after pointer, part 2</b></dt>
1297 <dd>
1298
1299 <p>This is related to the previous issue, c037. The following snippet was misparsed at the old style &#39; package separater due to the side comment following the pointer.</p>
1300
1301 <pre><code>    @ret
1302     =
1303     $o
1304     -&gt;#
1305     SUPER&#39;method
1306     (
1307     &#39;whatever&#39;
1308     )
1309     ;</code></pre>
1310
1311 <p>This is fixed in this update, case c041.</p>
1312
1313 <p>7 Jul 2021, 1806772.</p>
1314
1315 </dd>
1316 <dt id="Fix-problem-caused-by-side-comment-after-pointer"><b>Fix problem caused by side comment after pointer</b></dt>
1317 <dd>
1318
1319 <p>The following test script</p>
1320
1321 <pre><code>    is(
1322     $one
1323     -&gt;#sc#
1324     package
1325     ,
1326     &quot;bar&quot;
1327     ,
1328     &quot;Got package&quot;
1329     )
1330     ;</code></pre>
1331
1332 <p>Caused the following error message:</p>
1333
1334 <pre><code>  4: package
1335      ^
1336   found package where operator expected</code></pre>
1337
1338 <p>The problem was caused by a side comment between the pointer &#39;-&gt;&#39; and the word &#39;package&#39;. This caused package to be misparsed as a keyword, causing the error.</p>
1339
1340 <p>This is fixed in this update, case c037, 96f2ebb.</p>
1341
1342 </dd>
1343 <dt id="Fix-error-parsing-and-similar-combinations"><b>Fix error parsing &#39;%#&#39; and similar combinations</b></dt>
1344 <dd>
1345
1346 <p>Perltidy was correctly distinguishing between &#39;$#&#39; and &#39;$ #&#39; but not between &#39;@#&#39; and &#39;@ #&#39; and &#39;%#&#39; and &#39;% #&#39;. The coding for parsing these types of expressions has been corrected. Some simple examples:</p>
1347
1348 <pre><code>    # this is a valid program, &#39;%#&#39; is a punctuation variable
1349     %# = ( foo =&gt; &#39;bar&#39;, baz =&gt; &#39;buz&#39; );
1350     print keys(%#), &quot;\n&quot;;
1351
1352     # but this is a syntax error (space before # makes a side comment)
1353     # (perltidy was ignoring the space and forming &#39;%#&#39; here)
1354     % # = ( foo =&gt; &#39;bar&#39;, baz =&gt; &#39;buz&#39; );
1355     print keys(%#), &quot;\n&quot;;
1356
1357     # this is a valid program, &#39;@#&#39; is a punctuation variable
1358     @# = ( foo , &#39;bar&#39;, baz , &#39;buz&#39; );
1359     print @#, &quot;\n&quot;;
1360
1361     # this is a valid program, the space makes the &#39;#&#39; a side comment
1362     # perltidy formed %# here, causing an error
1363     % #
1364     var = ( foo =&gt; &#39;bar&#39;, baz =&gt; &#39;buz&#39; );
1365     print keys(%var), &quot;\n&quot;;</code></pre>
1366
1367 <p>This fixes case c036.</p>
1368
1369 <p>6 Jul 2021, e233d41.</p>
1370
1371 </dd>
1372 <dt id="Fix-error-parsing"><b>Fix error parsing &#39;&amp;#&#39;</b></dt>
1373 <dd>
1374
1375 <p>The following test script caused an error when perltidy did not correctly parse the tight side comment after the &#39;&amp;&#39; (it parsed correctly if there was a space before the &#39;#&#39;).</p>
1376
1377 <pre><code>    print$my_bag
1378     &amp;#sc#
1379     $your_bag
1380     ,
1381     &quot;\n&quot;
1382     ;</code></pre>
1383
1384 <p>This update fixes this issue, c033.</p>
1385
1386 <p>5 Jul 2021, 0d784e0.</p>
1387
1388 </dd>
1389 <dt id="Fix-error-parsing-format-statement"><b>Fix error parsing format statement</b></dt>
1390 <dd>
1391
1392 <p>The following test script caused an error when perltidy took &#39;format&#39; to start a format statement.</p>
1393
1394 <pre><code>    my$ascii#sc#
1395     =#sc#
1396     $formatter#sc#
1397     -&gt;#sc#
1398     format#sc#
1399     (#sc#
1400     $html#sc#
1401     )#sc#
1402     ;#sc#</code></pre>
1403
1404 <p>This was fixed by requiring a format statement to begin where a new statement can occur. This fixes issue c035.</p>
1405
1406 <p>5 Jan 2021, 2ef16fb.</p>
1407
1408 </dd>
1409 <dt id="Fix-some-incorrect-error-messages-due-to-side-comments"><b>Fix some incorrect error messages due to side comments</b></dt>
1410 <dd>
1411
1412 <p>Testing with large numbers of side comments caused perltidy to produce some incorrect error messages. Two issues are fixed with this update. First, a side comment between a pointer &#39;-&gt;&#39; and the next identifier caused a message. Second, in some cases a comment after an opening paren could cause a message. The following snippet is an example.</p>
1413
1414 <pre><code>    $Msg#sc#
1415     -&gt;#sc#
1416     $field#sc#
1417     (#sc#
1418     )#sc#
1419     ;#sc#</code></pre>
1420
1421 <p>This update fixes cases c029 and c030.</p>
1422
1423 <p>4 Jul 2021, caffc2c.</p>
1424
1425 </dd>
1426 <dt id="Fix-undefined-var-ref-involving---format-skipping"><b>Fix undefined var ref involving --format-skipping</b></dt>
1427 <dd>
1428
1429 <p>Testing produced a situation in which version 20200625 could cause an undefined variable to be accessed (the variable &#39;Ktoken_vars&#39;) as in this snippet:</p>
1430
1431 <pre><code>    #!/usr/bin/perl
1432     #&lt;&lt;&lt;
1433         my $ra= (
1434             [ &#39;Shine&#39;, 40 ], [ &#39;Specular&#39;, [ 1, 1, 0.3, 0 ] ] );
1435     #&lt;&lt;&lt;
1436     ...</code></pre>
1437
1438 <p>The conditions for this to happen are:</p>
1439
1440 <pre><code>  (1) format skipping (#&lt;&lt;&lt;) begins before the first line of code, and
1441   (2) the format skipping section contains the two successive characters &#39;, [&#39;.</code></pre>
1442
1443 <p>The undefined variable was &#39;Ktoken_vars&#39;. This problem was introduced by commit 21ef53b, an update which fixed case b1100. This undefined variable access does influence the formatted output.</p>
1444
1445 <p>This update fixes this problem.</p>
1446
1447 <p>4 Jul 2021, 82916fe.</p>
1448
1449 </dd>
1450 <dt id="Check-for-side-comment-within-package-statement"><b>Check for side comment within package statement</b></dt>
1451 <dd>
1452
1453 <p>Testing with randomly placed side comments caused perltidy to produce an incorrect warning when a side comment is placed before the end of a package statement:</p>
1454
1455 <pre><code>    package double # side comment
1456     ;</code></pre>
1457
1458 <p>This update fixes this. 3 Jul 2021, c00059a.</p>
1459
1460 </dd>
1461 <dt id="Fix-problem-with--comma-arrow-breakpoint-n-flag"><b>Fix problem with -comma-arrow-breakpoint=n flag</b></dt>
1462 <dd>
1463
1464 <p>Testing revealed a formatting irregularity which was caused when the flag -cab=2 got applied to a container which was not a list. This is fixed with update, which fixes case b939a.</p>
1465
1466 <p>1 Jul 2021, 021b938.</p>
1467
1468 </dd>
1469 <dt id="Fix-a-formatting-instability"><b>Fix a formatting instability</b></dt>
1470 <dd>
1471
1472 <p>Testing showed that a previously fixed case of instability, b1144, which was fixed 21 Jun 2021, 1b682fd, was unstable again. This update is a small change which fixes this. There are no other known unstable cases at this time but automated testing runs continue to search for instabilities.</p>
1473
1474 <p>1 Jul 2021, 021b938.</p>
1475
1476 </dd>
1477 <dt id="Fixed-use-of-uninitialized-value"><b>Fixed use of uninitialized value</b></dt>
1478 <dd>
1479
1480 <p>The previous Tokenizer update caused the use of an unitialized value when run on case b1053:</p>
1481
1482 <pre><code> Use of uninitialized value $next_nonblank_token in pattern match (m//) at /home/steve/bin/Perl/Tidy/Tokenizer.pm line 7589.
1483  Use of uninitialized value $nn_nonblank_token in pattern match (m//) at /home/steve/bin/Perl/Tidy/Tokenizer.pm line 3723.
1484  b1053 converged on iteration 2</code></pre>
1485
1486 <p>This update fixes this.</p>
1487
1488 <p>1 Jul 2021, ea139bd.</p>
1489
1490 </dd>
1491 <dt id="Fix-token-type-of-colon-introducing-anonomyous-sub-attribute-list"><b>Fix token type of colon introducing anonomyous sub attribute list</b></dt>
1492 <dd>
1493
1494 <p>In the following example</p>
1495
1496 <pre><code>    print &quot;not &quot; unless ref +(
1497         map {
1498             sub : lvalue { &quot;a&quot; }
1499         } 1
1500     )[0] eq &quot;CODE&quot;;</code></pre>
1501
1502 <p>the colon after &#39;sub&#39; was being marked as part of a label rather than the start of an attribute list. This does not cause an error, but the space before the &#39;:&#39; is lost. This is fixed in this update.</p>
1503
1504 <p>Note that something like &#39;sub :&#39; can also be a label, so the tokenizer has to look ahead to decide what to do. For example, this &#39;sub :&#39; is a label:</p>
1505
1506 <pre><code>    my $xx = 0;
1507     sub : {
1508         $xx++;
1509         print &quot;looping with label sub:, a=$xx\n&quot;;
1510         if ( $xx &lt; 10 ) { goto &quot;sub&quot; }
1511     }</code></pre>
1512
1513 <p>In this case, the goto statement needs quotes around &quot;sub&quot; because it is a keyword.</p>
1514
1515 <p>29 Jun 2021, d5fb3d5.</p>
1516
1517 </dd>
1518 <dt id="Minor-adjustments-to-improve-formatting-stability"><b>Minor adjustments to improve formatting stability</b></dt>
1519 <dd>
1520
1521 <p>Testing with random input parameters produced several new cases of formatting instability involving unusual parameter combinations. This update fixes these cases, b1169 b1170 b1171, and all previously discovered cases remain stable with the update.</p>
1522
1523 <p>28 Jun 2021, e1f22e0.</p>
1524
1525 </dd>
1526 <dt id="Remove-limit-on--ci-n-when--xci-is-set-see-rt-136415"><b>Remove limit on -ci=n when -xci is set, see rt #136415</b></dt>
1527 <dd>
1528
1529 <p>This update undoes the update c16c5ee of 20 Feb 2021, in which the value of -ci=n was limited to the value of -i=n when -xci was set. Recent improvements in stability tolerances allow this limit to be removed.</p>
1530
1531 <p>28 Jun 2021, 1b3c5e9.</p>
1532
1533 </dd>
1534 <dt id="Minor-optimization"><b>Minor optimization</b></dt>
1535 <dd>
1536
1537 <p>Added a quick check to bypass a needless sub call.</p>
1538
1539 <p>26 Jan 2021, e7822df.</p>
1540
1541 </dd>
1542 <dt id="Eliminate-token-variable-_LEVEL_TRUE_"><b>Eliminate token variable _LEVEL_TRUE_</b></dt>
1543 <dd>
1544
1545 <p>It was possible to eliminate this token variable by changing the order of welding operations. This reduces the number of variables per token from 12 to 11.</p>
1546
1547 <p>26 Jun 2021, 1f4f78c.</p>
1548
1549 </dd>
1550 <dt id="Eliminate-token-variable-_CONTAINER_ENVIRONMENT_"><b>Eliminate token variable _CONTAINER_ENVIRONMENT_</b></dt>
1551 <dd>
1552
1553 <p>Testing with NYT_Prof shows that the number of variables per token has a direct effect on efficiency. This update reduces the number of token variables from 13 to 12, and also simplifies the coding. It was possible to compute this variable from the others, so it was redundant.</p>
1554
1555 <p>26 Jun 2021, 300ca1e.</p>
1556
1557 </dd>
1558 </dl>
1559
1560 <h1 id="Issues-fixed-after-release-20210402">Issues fixed after release 20210402</h1>
1561
1562 <dl>
1563
1564 <dt id="Release-20210625"><b>Release 20210625</b></dt>
1565 <dd>
1566
1567 <p>24 Jun 2021, a4ff53d.</p>
1568
1569 </dd>
1570 <dt id="Adjust-tolerances-to-fix-some-unstable-edge-cases"><b>Adjust tolerances to fix some unstable edge cases</b></dt>
1571 <dd>
1572
1573 <p>Testing with random input parameters produced a number of edge cases of unstable formatting which were traced to the parameter combinations which included -lp and some other unusual settings.</p>
1574
1575 <p>This fixes cases b1103 b1134 b1135 b1136 b1138 b1140 b1143 b1144 b1145 b1146 b1147 b1148 b1151 b1152 b1153 b1154 b1156 b1157 b1163 b1164 b1165</p>
1576
1577 <p>There are no other known cases of formatting instability at the present time, but testing with random input parameters will continue.</p>
1578
1579 <p>21 Jun 2021, 1b682fd.</p>
1580
1581 </dd>
1582 <dt id="Adjust-tolerances-to-fix-some-unstable-edge-cases1"><b>Adjust tolerances to fix some unstable edge cases</b></dt>
1583 <dd>
1584
1585 <p>Testing with random input parameters produced a number of edge cases of unstable formatting which were traced to the parameter combinations which included -bbxi=2 and -cab=2. A small adjustment to length tolerances was made to fix the problem.</p>
1586
1587 <p>This fixes cases b1137 b1149 b1150 b1155 b1158 b1159 b1160 b1161 b1166 b1167 b1168.</p>
1588
1589 <p>19 Jun 2021, 4d4970a.</p>
1590
1591 </dd>
1592 <dt id="Added-flag--atnl---add-terminal-newline-see-git-58"><b>Added flag -atnl, --add-terminal-newline, see git #58</b></dt>
1593 <dd>
1594
1595 <p>This flag, which is enabled by default, allows perltidy to terminate the last line of the output stream with a newline character, regardless of whether or not the input stream was terminated with a newline character. If this flag is negated, with <b>-natnl</b>, then perltidy will add a terminal newline to the the output stream only if the input stream is terminated with a newline.</p>
1596
1597 <p>Negating this flag may be useful for manipulating one-line scripts intended for use on a command line.</p>
1598
1599 <p>This update also removes the description of the obsolete --check-syntax flag from the man pages and help text.</p>
1600
1601 <p>18 Jun 2021, 6f83170.</p>
1602
1603 </dd>
1604 <dt id="Allow---delete-side-comments-to-work-with--nanl"><b>Allow --delete-side-comments to work with -nanl</b></dt>
1605 <dd>
1606
1607 <p>The -nanl flag (--noadd-newlines) was preventing side comments from being deleted, for example:</p>
1608
1609 <pre><code>    # perltidy -dsc -nanl
1610     calc()    # side comment</code></pre>
1611
1612 <p>The same issue was happening for --delete-closing-side comments. This has been fixed.</p>
1613
1614 <p>18 Jun 2021, dbfd802.</p>
1615
1616 </dd>
1617 <dt id="Update-welding-rule-to-avoid-unstable-states"><b>Update welding rule to avoid unstable states</b></dt>
1618 <dd>
1619
1620 <p>Testing with random input parameters produced a formatting instability involving an unusual parameter combination:</p>
1621
1622 <pre><code>    --noadd-whitespace
1623     --break-before-paren=3
1624     --continuation-indentation=8
1625     --delete-old-whitespace
1626     --line-up-parentheses
1627     --weld-nested-containers</code></pre>
1628
1629 <p>and the following code</p>
1630
1631 <pre><code>        if(defined$hints{family}){
1632             @infos=({
1633                      family=&gt;$hints{family},
1634                      socktype=&gt;$hints{socktype},
1635                      protocol=&gt;$hints{protocol},
1636             });
1637         }</code></pre>
1638
1639 <p>This update fixes the problem, case b1162.</p>
1640
1641 <p>18 Jun 2021, 76873ea.</p>
1642
1643 </dd>
1644 <dt id="Convert-some-weld-sub-calls-to-hash-lookups"><b>Convert some weld sub calls to hash lookups</b></dt>
1645 <dd>
1646
1647 <p>This is a minor optimization. These subs are eliminated: is_welded_right_at_K, is_welded_left_at_K, weld_len_right_at_K.</p>
1648
1649 <p>17 Jun 2021, 1691013.</p>
1650
1651 </dd>
1652 <dt id="Update-LineSink.pm-to-allow-undefined-line-endings"><b>Update LineSink.pm to allow undefined line endings</b></dt>
1653 <dd>
1654
1655 <p>This update is necessary to eventually prevent an unwanted terminal newline being added to a file.</p>
1656
1657 <p>17 Jun 2021, 2600533.</p>
1658
1659 </dd>
1660 <dt id="Fix-incorrect-sub-call"><b>Fix incorrect sub call</b></dt>
1661 <dd>
1662
1663 <p>This fixes an incorrect call which could cause an incorrect weld.</p>
1664
1665 <p>16 Jun 2021, 068a28b.</p>
1666
1667 </dd>
1668 <dt id="Add---code-skipping-option-see-git-65"><b>Add --code-skipping option, see git #65</b></dt>
1669 <dd>
1670
1671 <p>Added a new option &#39;--code-skipping&#39;, requested in git #65, in which code between comment lines &#39;#&lt;&lt;V&#39; and &#39;#&gt;&gt;V&#39; is passed verbatim to the output stream without error checking. It is simmilar to --format skipping but there is no error checking, and is useful for skipping an extended syntax.</p>
1672
1673 <p>16 Jun 2021, 99ec876.</p>
1674
1675 </dd>
1676 <dt id="Handle-nested-print-format-blocks"><b>Handle nested print format blocks</b></dt>
1677 <dd>
1678
1679 <p>Perltidy was producing an error at nested print format blocks, such as</p>
1680
1681 <pre><code>    format NEST =
1682     @&lt;&lt;&lt;
1683     {
1684         my $birds = &quot;birds&quot;;
1685         local *NEST = *BIRDS{FORMAT};
1686         write NEST;
1687         format BIRDS =
1688     @&lt;&lt;&lt;&lt;&lt;
1689     $birds;
1690     .
1691     &quot;nest&quot;
1692       }
1693     .</code></pre>
1694
1695 <p>It was ending the first format at the first &#39;.&#39; rather than the second &#39;.&#39; in this example. This update fixes this, issue c019.</p>
1696
1697 <p>13 Jun 2021.</p>
1698
1699 </dd>
1700 <dt id="Allow-stacked-labels-without-spaces"><b>Allow stacked labels without spaces</b></dt>
1701 <dd>
1702
1703 <p>When labels are stacked in a single line, such as</p>
1704
1705 <p>A:B:C:</p>
1706
1707 <p>the default is to space them:</p>
1708
1709 <p>A: B: C:</p>
1710
1711 <p>This update allows the spaces to be removed if desired:</p>
1712
1713 <p># perltidy -naws -dws A:B:C:</p>
1714
1715 <p>13 Jun 2021, c2a63b2</p>
1716
1717 </dd>
1718 <dt id="Fix-edge-cases-of-instability-involving--wn--lp"><b>Fix edge cases of instability involving -wn -lp</b></dt>
1719 <dd>
1720
1721 <p>Random testing produced some cases of instability involving -wn -lp and some unusual additional parameters. These were traced to a test for welding, and were fixed by refining a certain tolerance. This fixes cases b1141, b1142.</p>
1722
1723 <p>12 Jun 2021, 125494b.</p>
1724
1725 </dd>
1726 <dt id="Remove-incorrect-warning-at-repeated-function-paren-call"><b>Remove incorrect warning at repeated function paren call</b></dt>
1727 <dd>
1728
1729 <p>This update removes an incorrect error messagge at the construct &#39;)(&#39;. To illustrate, the following is a valid program:</p>
1730
1731 <pre><code>    my @words = qw(To view this email as a web page go here);
1732     my @subs;
1733     push @subs, sub { my $i=shift; $i %= @words; print &quot;$words[$i] &quot;; return $subs[0]};
1734     $subs[0](0)(1)(2)(3)(4)(5)(6)(7)(8)(9)(10)(11);
1735     print &quot;\n&quot;;</code></pre>
1736
1737 <p>However perltidy was giving an error message at the &#39;)(&#39; combination, which is unusual in perl scripts. This update fixes this.</p>
1738
1739 <p>These are function call parens, so logically they should be under control of the -sfp or --space-function-parens parameter. I wrote a patch to do this, but decided not to implement it. The reason is that, as noted in the manual, subtle errors in perl scripts can occur when spaces are placed before parens. So, to avoid possible problems, the -sfp parameter will be restricted to spaces between a bareword [assumed to be a function] and a paren.</p>
1740
1741 <p>This update is in Tokenizer.pm and fixes case c017.</p>
1742
1743 <p>6 Jun 2021, 6551d65.</p>
1744
1745 </dd>
1746 <dt id="Add-warning-when-lexical-sub-names-match-some-builtins"><b>Add warning when lexical sub names match some builtins</b></dt>
1747 <dd>
1748
1749 <p>This update adds a warning when lexical subs have names which match some builtin names which will almost certainly cause a parsing error in the current version of perltidy. For example, the following program is valid and will run, but perltidy will produce an error.</p>
1750
1751 <pre><code>    use feature qw(lexical_subs);
1752     use warnings; no warnings &quot;experimental::lexical_subs&quot;;
1753     {
1754       my sub y { print &quot;Hello from y: $_[0]\n&quot;; }
1755       y(1);
1756     }</code></pre>
1757
1758 <p>6 Jun 2021, 32729fb.</p>
1759
1760 </dd>
1761 <dt id="Minor-cleanups"><b>Minor cleanups</b></dt>
1762 <dd>
1763
1764 <p>This update fixes a case of formatting instability recently found with random testing. It also does some minor coding cleanups.</p>
1765
1766 <p>This fixes case b1139.</p>
1767
1768 <p>5 Jun 2021, b8527ab.</p>
1769
1770 </dd>
1771 <dt id="Revised-data-structures-for-welding"><b>Revised data structures for welding</b></dt>
1772 <dd>
1773
1774 <p>This update replaces the data structures used for the welding option with simpler but more general structures. This cleans up the code and will simplify future coding. No formatting changes should occur with this update.</p>
1775
1776 <p>4 Jun 2021, 4a886c8.</p>
1777
1778 </dd>
1779 <dt id="improved-treatment-of-lexical-subs"><b>improved treatment of lexical subs</b></dt>
1780 <dd>
1781
1782 <p>This update improves the treatment of lexical subs. Previously they were formatted correctly but an error would have been produced if the same name was used for lexical subs defined in different blocks.</p>
1783
1784 <p>For example, running the previous version of perltidy on the following:</p>
1785
1786 <pre><code>    use feature qw(lexical_subs);
1787     use warnings; no warnings &quot;experimental::lexical_subs&quot;;
1788     {
1789         my sub hello { print &quot;Hello from hello1\n&quot; }
1790         {
1791             my sub hello { print &quot;Hello from hello2\n&quot; }
1792             hello();
1793         }
1794         hello();
1795     }
1796     {
1797         my sub hello { print &quot;Hello from hello3\n&quot; }
1798         hello();
1799     }</code></pre>
1800
1801 <p>gave the (incorrect) error message:</p>
1802
1803 <pre><code>    6: already saw definition of &#39;sub hello&#39; in package &#39;main&#39; at line 4
1804     12: already saw definition of &#39;sub hello&#39; in package &#39;main&#39; at line 6</code></pre>
1805
1806 <p>This update fixes that.</p>
1807
1808 <p>1 Jun 2021, 85ecb7a.</p>
1809
1810 </dd>
1811 <dt id="add-v-string-underscores-warn-of-leading-commas"><b>add v-string underscores; warn of leading commas</b></dt>
1812 <dd>
1813
1814 <p>This update cleans up a couple of open issues in the tokenizer.</p>
1815
1816 <p>A warning message will be produced for a list which begins with a comma:</p>
1817
1818 <pre><code>            my %string = (
1819               ,       &quot;saddr&quot;,    $stest,  &quot;daddr&quot;,
1820               $dtest, &quot;source&quot;,   $sname,  &quot;dest&quot;)</code></pre>
1821
1822 <p>This warning had been temporarily deactivated.</p>
1823
1824 <p>Underscores in v-strings without a leading &#39;v&#39; are now parsed correctly.</p>
1825
1826 <p>Several comments have been updated.</p>
1827
1828 <p>31 May 2021, ef44e70.</p>
1829
1830 </dd>
1831 <dt id="Fix-parsing-error-at-operator-following-a-comma"><b>Fix parsing error at operator following a comma</b></dt>
1832 <dd>
1833
1834 <p>The following lines are syntactically correct but some were producing a syntax error</p>
1835
1836 <pre><code>    print &quot;hello1\n&quot;, || print &quot;hi1\n&quot;;
1837     print &quot;hello2\n&quot;, &amp;&amp; print &quot;bye2\n&quot;;
1838     print &quot;hello3\n&quot;, or print &quot;bye3\n&quot;;
1839     print &quot;hello4\n&quot;, and print &quot;bye4\n&quot;;</code></pre>
1840
1841 <p>For example, the first line produced this message</p>
1842
1843 <pre><code>    1: print &quot;hello1\n&quot;, || print &quot;hi1\n&quot;;
1844                        - ^
1845     found || where term expected (previous token underlined)</code></pre>
1846
1847 <p>This has been fixed. This fixes case c015.</p>
1848
1849 <p>27 May 2021, b537a72.</p>
1850
1851 </dd>
1852 <dt id="Added-optional-o-in-octal-number-definitions"><b>Added optional o in octal number definitions</b></dt>
1853 <dd>
1854
1855 <p>An optional letter &#39;o&#39; or &#39;O&#39; in the octal representation of numbers, which was added in perl version 5.33.5, is now recogized. The leading zero is still required.</p>
1856
1857 <p>For example:</p>
1858
1859 <pre><code>    $a = 0o100;
1860     $a = 0O100;</code></pre>
1861
1862 <p>26 May 2021, 544df8c.</p>
1863
1864 </dd>
1865 <dt id="Fix-several-problems-with--lp-formatting"><b>Fix several problems with -lp formatting</b></dt>
1866 <dd>
1867
1868 <p>This update fixes several problems with -lp formatting which are all somewhat related.</p>
1869
1870 <p>ISSUE #1 (cases c002 and c004): A problem involving -lp -wn and certain qw lists</p>
1871
1872 <p>The last line of a welded qw list was being outdented even if it contained text as well as the closing container token. This update fixes the problem and simplifies the logic.</p>
1873
1874 <p>A few examples (all use &#39;perltidy -wn -lp&#39;):</p>
1875
1876 <pre><code>    # OLD and NEW: OK, closing qw paren is on separate line
1877     $roads-&gt;add_capacity_path( qw( CoolCity 10 ChocolateGulch 8
1878                                PecanPeak 10 BlueberryWoods 6
1879                                HotCity
1880     ) );
1881
1882     # OLD: poor; outdented text not aligned with previous text
1883     $roads-&gt;add_capacity_path( qw( CoolCity 10 ChocolateGulch 8
1884                                PecanPeak 10 BlueberryWoods 6
1885     HotCity ) );
1886
1887     # NEW:
1888     $roads-&gt;add_capacity_path( qw( CoolCity 10 ChocolateGulch 8
1889                                PecanPeak 10 BlueberryWoods 6
1890                                HotCity ) );
1891
1892     # OLD:
1893     $roads-&gt;add_capacity_path( qw( ChocolateGulch 3 StrawberryFields 0
1894     StrawberryFields ) );
1895
1896     # NEW:
1897     $roads-&gt;add_capacity_path( qw( ChocolateGulch 3 StrawberryFields 0
1898                                StrawberryFields ) );
1899
1900     # OLD:
1901     my $mon_name = ( qw(January February March April
1902                      May June July August
1903     September October November December) )[$mon];
1904
1905     # NEW
1906     my $mon_name = ( qw(January February March April
1907                      May June July August
1908                      September October November December) )[$mon];</code></pre>
1909
1910 <p>ISSUE #2 (case c007): A rare program error could be triggered with -lp -xci</p>
1911
1912 <p>In some very rare circumstances it was possible to trigger a &quot;Program error&quot; message. The program still ran to completion. The conditions for this to occur were that flags -lp -xci were set, and that there was a container of sort/map/grep blocks, and there was a side comment on the closing paren. For example:</p>
1913
1914 <pre><code>    # OLD: perltidy -lp -xci, gave an error message and extra indentation here
1915     my %specified_opts = (
1916           (
1917                           map { /^no-?(.*)$/i ? ($1 =&gt; 0) : ($_ =&gt; 1) }
1918                           map { /^--([\-_\w]+)$/ } @ARGV
1919           ),    # this comment caused an error with flags -lp -xci
1920     );
1921
1922     # NEW: perltidy -lp -xci, no error
1923     my %specified_opts = (
1924           (
1925              map { /^no-?(.*)$/i ? ( $1 =&gt; 0 ) : ( $_ =&gt; 1 ) }
1926              map { /^--([\-_\w]+)$/ } @ARGV
1927           ),    # this comment caused an error with flags -lp -xci
1928     );</code></pre>
1929
1930 <p>ISSUE #3 (case c008): In some unusual cases the -lp formatting style was not being applied when it should have been. For example (text is shifted right):</p>
1931
1932 <pre><code>    # NEW: perltidy -lp
1933     $result = runperl(
1934         switches =&gt; [ &#39;-I.&#39;, &quot;-w&quot; ],
1935         stderr   =&gt; 1,
1936         prog     =&gt; &lt;&lt;&#39;PROG&#39; );
1937     SIG
1938     PROG
1939
1940     # NEW: perltidy -lp
1941     $result = runperl(
1942                        switches =&gt; [ &#39;-I.&#39;, &quot;-w&quot; ],
1943                        stderr   =&gt; 1,
1944                        prog     =&gt; &lt;&lt;&#39;PROG&#39; );
1945     SIG
1946     PROG</code></pre>
1947
1948 <p>25 May 2021, 6947fe9.</p>
1949
1950 </dd>
1951 <dt id="Modify-welding-rules"><b>Modify welding rules</b></dt>
1952 <dd>
1953
1954 <p>This is an update to the patch 19 Apr 2021, eeeaf09. It restricts that patch to -lp formatting mode.</p>
1955
1956 <p>This fixes case b1131.</p>
1957
1958 <p>21 May 2021, a4ec4c1.</p>
1959
1960 </dd>
1961 <dt id="Fix-inconsistency-involving-counting-commas"><b>Fix inconsistency involving counting commas</b></dt>
1962 <dd>
1963
1964 <p>Random testing produced a formatting instability involving the combination of flags -bbp=2 -xci -vt=2 -bvtc=2. The problem was traced to an error in counting the number of line ending commas in lists.</p>
1965
1966 <p>This fixes case b1130.</p>
1967
1968 <p>15 May 2021, 90cceb1.</p>
1969
1970 </dd>
1971 <dt id="Slightly-modify-line-breaks-for--lp-indentation"><b>Slightly modify line breaks for -lp indentation</b></dt>
1972 <dd>
1973
1974 <p>Random testing produced an edge case of formatting instability for -lp indentation which was traced to checking for an old line break at a &#39;=&gt;&#39;. This has been fixed. Some existing formatting with deeply nested structures may be slightly changed due to the fix, but most existing formatting will be unchanged.</p>
1975
1976 <p>This fixes b1035.</p>
1977
1978 <p>15 May 2021, dd42648.</p>
1979
1980 </dd>
1981 <dt id="Rewrite-coding-for--bom-flag"><b>Rewrite coding for -bom flag</b></dt>
1982 <dd>
1983
1984 <p>Random testing produced some examples of formatting instability involving the -bom flag in combination with certain other flags which are fixed with this update. As part of this update, a previous update to fix case b977 (21 Feb 2021, commit 28114e9) was revised to use a better criterion for deciding when not to keep a &#39;)-&gt;&#39; break. The previous criterion was that the opening and closing containers should be separated by more than one line. The new criterion is that they should contain a list. This still fixes case b977. Another case, b1120, was fixed by requiring that only parentheses expressions be considered for keeping a line break, not &#39;}-&gt;&#39; or &#39;]-&gt;&#39;.</p>
1985
1986 <p>Some issues are illustrated in the following examples using &#39;-bom -gnu&#39;. In the first example the leading &#39;)-&gt;&#39; was being lost due to the old b977 fix:</p>
1987
1988 <pre><code>    # input:
1989     $show = $top-&gt;Entry( &#39;-width&#39; =&gt; 20,
1990                        )-&gt;pack(&#39;-side&#39; =&gt; &#39;left&#39;);
1991
1992     # OLD: perltidy -gnu -bom
1993     $show = $top-&gt;Entry(&#39;-width&#39; =&gt; 20,)-&gt;pack(&#39;-side&#39; =&gt; &#39;left&#39;);
1994
1995     # NEW: perltidy -gnu -bom
1996     $show = $top-&gt;Entry(
1997                         &#39;-width&#39; =&gt; 20,
1998                        )-&gt;pack(&#39;-side&#39; =&gt; &#39;left&#39;);</code></pre>
1999
2000 <p>In the following example a leading &#39;-&gt;&#39; was being lost. The NEW version keeps the leading &#39;-&gt;&#39; but has to give up on the -lp alignment because of complexity:</p>
2001
2002 <pre><code>        # input
2003         $_make_phase_arg = join(&quot; &quot;,
2004                            map {CPAN::HandleConfig
2005                                  -&gt;safe_quote($_)} @{$prefs-&gt;{$phase}{args}},
2006                           );
2007
2008         # OLD: perltidy -gnu -bom
2009         $_make_phase_arg = join(&quot; &quot;,
2010                                 map { CPAN::HandleConfig-&gt;safe_quote($_) }
2011                                   @{$prefs-&gt;{$phase}{args}},
2012                                );
2013
2014         # NEW: perltidy -gnu -bom
2015         $_make_phase_arg = join(
2016             &quot; &quot;,
2017             map {
2018                 CPAN::HandleConfig
2019                   -&gt;safe_quote($_)
2020             } @{$prefs-&gt;{$phase}{args}},
2021         );</code></pre>
2022
2023 <p>In the following example, a leading &#39;)-&gt;&#39; was being converted to a leading &#39;-&gt;&#39; due to the old b977 fix:</p>
2024
2025 <pre><code>    # Starting script
2026     $lb = $t-&gt;Scrolled(&quot;Listbox&quot;, -scrollbars =&gt; &quot;osoe&quot;
2027                       )-&gt;pack(-fill =&gt; &quot;both&quot;, -expand =&gt; 1);
2028
2029     # OLD: perltidy -bom -gnu
2030     $lb = $t-&gt;Scrolled( &quot;Listbox&quot;, -scrollbars =&gt; &quot;osoe&quot; )
2031       -&gt;pack( -fill =&gt; &quot;both&quot;, -expand =&gt; 1 );
2032
2033     # NEW: perltidy -bom -gnu
2034     $lb = $t-&gt;Scrolled(
2035                        &quot;Listbox&quot;, -scrollbars =&gt; &quot;osoe&quot;
2036                       )-&gt;pack(-fill =&gt; &quot;both&quot;, -expand =&gt; 1);</code></pre>
2037
2038 <p>In the following example, a leading &#39;)-&gt;&#39; was being lost, again due to the old b977 fix:</p>
2039
2040 <pre><code>    $myDiag-&gt;Label(-text =&gt; $text,
2041                                   )-&gt;pack(-fill =&gt; &#39;x&#39;,
2042                                                   -padx =&gt; 3,
2043                                                   -pady =&gt; 3);
2044
2045     # OLD: -gnu -bom
2046     $myDiag-&gt;Label(-text =&gt; $text,)-&gt;pack(
2047                                           -fill =&gt; &#39;x&#39;,
2048                                           -padx =&gt; 3,
2049                                           -pady =&gt; 3
2050                                          );
2051
2052     # NEW -gnu -bom
2053     $myDiag-&gt;Label(
2054                    -text =&gt; $text,
2055       )-&gt;pack(
2056               -fill =&gt; &#39;x&#39;,
2057               -padx =&gt; 3,
2058               -pady =&gt; 3
2059              );</code></pre>
2060
2061 <p>This update fixes case b1120 and revises the fix for b977.</p>
2062
2063 <p>13 May 2021, d0ac5e9.</p>
2064
2065 </dd>
2066 <dt id="Adjust-tolerances-for-some-line-length-tests"><b>Adjust tolerances for some line length tests</b></dt>
2067 <dd>
2068
2069 <p>Random testing produced some edge cases of unstable formatting involving the -lp format. These were fixed by using a slightly larger tolerance in the length test for containers which were broken in the input file.</p>
2070
2071 <p>This fixes cases b1059 b1063 b1117.</p>
2072
2073 <p>13 May 2021, 24a11d3.</p>
2074
2075 </dd>
2076 <dt id="Do-not-apply--lp-formatting-to-containers-with-here-doc-text"><b>Do not apply -lp formatting to containers with here-doc text</b></dt>
2077 <dd>
2078
2079 <p>If a container contains text of a here-doc then the indentation is fixed by the here-doc text, so applying -lp formatting does not work well. So this update turns off the -lp formatting in this case.</p>
2080
2081 <p>But note that if a container contains a here target but not the here text so it still gets the -lp indentation:</p>
2082
2083 <pre><code>    # perltidy -lp
2084     &amp;WH::Spell::AddSpell(
2085                           &quot;Cause Light Wounds&quot;, &quot;WFP&quot;,
2086                           &quot;CauseLightWounds&quot;,   &lt;&lt;&#39;EOH&#39;);
2087     ...
2088     EOH</code></pre>
2089
2090 <p>This fixes case b1081.</p>
2091
2092 <p>10 May 2021, 4f7a56b.</p>
2093
2094 </dd>
2095 <dt id="Fix-some-edge-welding-cases"><b>Fix some edge welding cases</b></dt>
2096 <dd>
2097
2098 <p>Some adjustments in welding coding was made to maintain stability for some unusual parameter combinations.</p>
2099
2100 <p>This fixes cases b1111 b1112.</p>
2101
2102 <p>9 May 2021, 68f619a.</p>
2103
2104 </dd>
2105 <dt id="Improve-tolerance-for-welding-qw-quotes"><b>Improve tolerance for welding qw quotes</b></dt>
2106 <dd>
2107
2108 <p>The tolerance for welding qw quotes has been update to be the same as used for welding other tokens. This fixes case b1129.</p>
2109
2110 <p>9 May 2021, d1de85f.</p>
2111
2112 </dd>
2113 <dt id="Revise-weld-tolerances-simplify-code-fix-welded-ci"><b>Revise weld tolerances, simplify code, fix welded ci</b></dt>
2114 <dd>
2115
2116 <p>The welding process uses a tolerance to keep results stable. Basically, a zero tolerance is used if it looks like it is welding an existing weld, while a finite tolerance is used otherwise. The effect is to reject a few marginal welds to gain stability. The coding to do this was simplified and the tolerance was made more precise to fix case b1124.</p>
2117
2118 <p>Another change with this update is that at welded containers, the value of the -ci flag of an outer opening token is transferred to the inner opening token. This may improve some indentation in a few cases if the -lp flag is also used. It has no effect if -lp is not used.</p>
2119
2120 <pre><code>    # OLD: perltidy -wn -gnu
2121     emit_symbols([qw(
2122      ctermid
2123      get_sysinfo
2124      Perl_OS2_init
2125      ...
2126      CroakWinError
2127     )]);
2128
2129     # NEW: perltidy -wn -gnu
2130     emit_symbols([qw(
2131         ctermid
2132         get_sysinfo
2133         Perl_OS2_init
2134         ...
2135         CroakWinError
2136     )]);</code></pre>
2137
2138 <p>9 May 2021, ad8870b.</p>
2139
2140 </dd>
2141 <dt id="Correct-brace-types-mismarked-by-tokenizer-update"><b>Correct brace types mismarked by tokenizer, update</b></dt>
2142 <dd>
2143
2144 <p>This is a generalization of commit 7d3bf4 in which the tokenizer sends a signal to the formatter if the type of a brace following an unknown bareword had to be guessed. The formatter has more information and can fix the problem. This fixes case b1128.</p>
2145
2146 <p>8 May 2021, b3eaf23.</p>
2147
2148 </dd>
2149 <dt id="Added-warning-when--ci-has-to-be-reduced-ref-rt-136415"><b>Added warning when -ci has to be reduced; ref rt #136415</b></dt>
2150 <dd>
2151
2152 <p>In commit c16c5ee an update was made to prevent instability with -xci when the value of -ci exceeds -i (which is not recommended). This update adds a warning message to avoid confusing the user.</p>
2153
2154 <p>7 May 2021, e9e14e4.</p>
2155
2156 </dd>
2157 <dt id="Improve-indentation-of-welded-multiline-qw-quotes"><b>Improve indentation of welded multiline qw quotes</b></dt>
2158 <dd>
2159
2160 <p>Formatting of multiline qw lists with welding works best if the opening and closing qw tokens are on separate lines, like this:</p>
2161
2162 <pre><code>    # perltidy -wn
2163     my $mon_name = ( qw(
2164         January February March April
2165         May June July August
2166         September October November December
2167     ) )[$mon];
2168
2169     # perltidy -wn -lp
2170     my $mon_name = ( qw(
2171                      January February March April
2172                      May June July August
2173                      September October November December
2174     ) )[$mon];</code></pre>
2175
2176 <p>Otherwise formatting can be poor, particularly if the last line has text and a closing container.</p>
2177
2178 <pre><code>    # OLD: perltidy -wn
2179     my $mon_name = ( qw(January February March April
2180         May June July August
2181     September October November December) )[$mon];</code></pre>
2182
2183 <p>Note that perltidy does not change the line breaks within multiline quotes, so they must be changed by hand if desired.</p>
2184
2185 <p>This update indents the last line of a multiline quote which contains both text and the closing token, such as:</p>
2186
2187 <pre><code>    # NEW: perltidy -wn
2188     my $mon_name = ( qw(January February March April
2189         May June July August
2190         September October November December) )[$mon];</code></pre>
2191
2192 <p>This update is only when the -lp flag is not used. If -lp is used and the last line contains text, the last line is still outdented:</p>
2193
2194 <pre><code>    $ OLD and NEW: perltidy -wn -lp
2195     my $mon_name = ( qw(January February March April
2196                      May June July August
2197     September October November December) )[$mon];</code></pre>
2198
2199 <p>This is difficult to fix. The best solution is to place the closing qw qw containers on a separate line.</p>
2200
2201 <p>This fix is for case c002.</p>
2202
2203 <p>6 May 2021, 176f8a7.</p>
2204
2205 </dd>
2206 <dt id="Test-length-of-closing-multiline-qw-quote-before-welding"><b>Test length of closing multiline qw quote before welding</b></dt>
2207 <dd>
2208
2209 <p>Random testing produced an unstable state which was due to not checking for excessive length of the last line of a multiline qw quote. A check was added, this fixes issue b1039.</p>
2210
2211 <p>5 May 2021, b72ad24.</p>
2212
2213 </dd>
2214 <dt id="Update-welding-rule-to-avoid-blinking-states"><b>Update welding rule to avoid blinking states</b></dt>
2215 <dd>
2216
2217 <p>Random testing with unusual parameter combinations produced some unstable welds. For example case b1106 has these parameters</p>
2218
2219 <pre><code>    --noadd-whitespace
2220     --continuation-indentation=6
2221     --delete-old-whitespace
2222     --line-up-parentheses
2223     --maximum-line-length=36
2224     --variable-maximum-line-length
2225     --weld-nested-containers</code></pre>
2226
2227 <p>and was switching between these two states:</p>
2228
2229 <pre><code>            return map{
2230                 ($_,[$self-&gt;$_(@_[1..$#_])])
2231             }@every;
2232
2233             return map { (
2234                 $_, [ $self-&gt;$_( @_[ 1 .. $#_ ] ) ]
2235             ) } @every;</code></pre>
2236
2237 <p>An existing rule, WELD RULE 2, was updated to prevent welding to an intact one-line weld, as in the first snippet, if it is on a separate line from the first opening token. With this change, both of these states are stable.</p>
2238
2239 <p>This update fixes cases b1082 b1102 b1106 b1115.</p>
2240
2241 <p>4 May 2021, 07efa9d.</p>
2242
2243 </dd>
2244 <dt id="Fix-problem-of-conflict-of--otr-and--lp"><b>Fix problem of conflict of -otr and -lp</b></dt>
2245 <dd>
2246
2247 <p>Several random test cases produced an instability involving -otr and -lp. In -lp mode, when an opening paren follows an equals and is far to the right, a break is made at the equals to minimize the indentation of the next lines. The -otr flag is a suggestion that an opening paren should be place on the right. A check has been made to avoid this in -lp mode following an equals, since that defeats the purpose of the original break.</p>
2248
2249 <p>This fixes cases b964 b1040 b1062 b1083 b1089.</p>
2250
2251 <p>4 May 2021, 24a0d32.</p>
2252
2253 </dd>
2254 <dt id="Add-option--pvtc-3-requested-in-rt136417"><b>Add option -pvtc=3, requested in rt136417</b></dt>
2255 <dd>
2256
2257 <p>A new integer option, n=3, has been added to the vertical tightness closing flags. For a container with n=3, the closing token will behave as for n=0 if the opening token is preceded by an &#39;=&#39; or &#39;=&gt;&#39;, and like n=1 otherwise.</p>
2258
2259 <p>3 May 2021, 93063a7.</p>
2260
2261 </dd>
2262 <dt id="Fix-vertical-alignment-issue-in-rt136416"><b>Fix vertical alignment issue in rt136416</b></dt>
2263 <dd>
2264
2265 <p>This update fixes a problem with unwanted vertical alignment rasied in rt#136416. The example is</p>
2266
2267 <pre><code>    use File::Spec::Functions &#39;catfile&#39;, &#39;catdir&#39;;
2268     use Mojo::Base &#39;Mojolicious&#39;,        &#39;-signatures&#39;;</code></pre>
2269
2270 <p>An update was made to reject alignments in use statements with different module names. The test file t/snippets/align35.in has more examples.</p>
2271
2272 <p>3 May 2021, 048126c.</p>
2273
2274 </dd>
2275 <dt id="Fix-some-rare-issues-with-the--lp-option"><b>Fix some rare issues with the -lp option</b></dt>
2276 <dd>
2277
2278 <p>Random testing produced some rare cases of unstable formatting involving the <b>-lp</b> option which are fixed with this update. This is a generalization of commit edc7878 of 23 Jan 2021. This fixes cases b1109 b1110.</p>
2279
2280 <p>2 May 2021, a8d1c8b.</p>
2281
2282 </dd>
2283 <dt id="Correct-brace-types-mismarked-by-tokenizer"><b>Correct brace types mismarked by tokenizer</b></dt>
2284 <dd>
2285
2286 <p>This is a generalization of commit 7d23bf4 to fix some additional cases found in random testing in which the type of a curly brace could not be determined in the tokenizer and was not being corrected by the formatter.</p>
2287
2288 <p>This fixes cases b1125 b1126 b1127.</p>
2289
2290 <p>2 May 2021, dac97cb.</p>
2291
2292 </dd>
2293 <dt id="Avoid-instability-of-combination--bbx-2--lp-and--xci"><b>Avoid instability of combination -bbx=2 -lp and -xci</b></dt>
2294 <dd>
2295
2296 <p>Random testing produced several cases in which the flags -bbx=2 -lp and -xci were causing formatting instability. The fix is to locally turn off -xci when -lp and -bbx=2 are in effect. This is an extension of commit 2b05051.</p>
2297
2298 <p>This fixes cases b1090 b1095 b1101 b1116 b1118 b1121 b1122 b1099</p>
2299
2300 <p>1 May 2021, 4cb81ba.</p>
2301
2302 </dd>
2303 <dt id="Restrict-use-of-flag--cab-3-to-simple-structures"><b>Restrict use of flag -cab=3 to simple structures</b></dt>
2304 <dd>
2305
2306 <p>Logic was added to turn off -cab=3 in complex structures. Otherwise, instability can occur. When it is overridden the behavior of the closest match, -cab=2, is used instead.</p>
2307
2308 <p>For example, using these parameters for case b1113</p>
2309
2310 <pre><code>    --noadd-whitespace
2311     --break-before-hash-brace-and-indent=2
2312     --break-before-hash-brace=1
2313     --comma-arrow-breakpoints=3
2314     --continuation-indentation=9
2315     --maximum-line-length=76
2316     --variable-maximum-line-length</code></pre>
2317
2318 <p>formatting of the following snippet was unstable:</p>
2319
2320 <pre><code>    $STYLESHEET{&#39;html-light&#39;}={
2321         &#39;tags&#39;=&gt;{
2322             &#39;predefined identifier&#39;=&gt;
2323                      {
2324                 &#39;start&#39;=&gt;&#39;&lt;font color=&quot;#2040a0&quot;&gt;&lt;strong&gt;&#39;,
2325                 &#39;stop&#39;=&gt;&#39;&lt;/strong&gt;&lt;/font&gt;&#39;
2326                      },
2327         }
2328     };</code></pre>
2329
2330 <p>This update fixes cases b1096 b1113.</p>
2331
2332 <p>29 Apr 2021, 32a1830.</p>
2333
2334 </dd>
2335 <dt id="Update-docs-for-git-64-regarding--lp-and-side-comments"><b>Update docs for git #64 regarding -lp and side comments</b></dt>
2336 <dd>
2337
2338 <p>The wording regarding when -lp reverts to the default indentation scheme has been revised to include side comment as follows:</p>
2339
2340 <p>In situations where perltidy does not have complete freedom to choose line breaks it may temporarily revert to its default indentation method. This can occur for example if there are blank lines, block comments, multi-line quotes, or side comments between the opening and closing parens, braces, or brackets.</p>
2341
2342 <p>The word &#39;may&#39; is significant for side comments. In a list which is just one level deep side comments will work (perhaps with -iscl if side comments are long). For example this is ok</p>
2343
2344 <pre><code>    # perltidy -lp
2345     $gif-&gt;arc(
2346                50, 50,     # Center x, y.
2347                30, 30,     # Width, Height.
2348                0,  360,    # Start Angle, End Angle.
2349                $red
2350     );</code></pre>
2351
2352 <p>But if a list is more than one level deep then the default indentation is used.</p>
2353
2354 <p>28 Apr 2021, 49977b8.</p>
2355
2356 </dd>
2357 <dt id="Fix-line-break-rules-for-uncontained-commas-cleanups"><b>Fix line break rules for uncontained commas + cleanups</b></dt>
2358 <dd>
2359
2360 <p>This is an adjustment of update 344519e which had to do with breaking lines with commas which were not inside of a container. In a few cases it was producing very long lines when <b>-l=0</b> was set. The solution was to remove the concatenation operator from the list of operators at which breaks were prevented.</p>
2361
2362 <p>Other updates are: Remove unused indentation table. Correct maximum_line_length table for -vmll when -wc is also set. Also fix whitespace rule for &#39;$ =&#39; within a signature to fix case b1123.</p>
2363
2364 <p>26 Apr 2021, d014c2a.</p>
2365
2366 </dd>
2367 <dt id="Fix-problem-with--wn-and--wc-n"><b>Fix problem with -wn and -wc=n</b></dt>
2368 <dd>
2369
2370 <p>Random testing produced some cases in which the -wn flag was unstable when -wc=n was used with very small n. This has been fixed.</p>
2371
2372 <p>This fixes cases: b1098 b1107 25 Apr 2021, 92babdf.</p>
2373
2374 </dd>
2375 <dt id="Adjust-line-break-rules-for-uncontained-commas"><b>Adjust line break rules for uncontained commas</b></dt>
2376 <dd>
2377
2378 <p>Random testing produced case c1119 which was unstable due to the formatting rules for breaking lines at commas which occur outside of containers. The rules were modified to fix the problem.</p>
2379
2380 <p>20 Apr 2021, 344519e.</p>
2381
2382 </dd>
2383 <dt id="Fix-a-bad-line-break-choice-at-a-slash"><b>Fix a bad line break choice at a slash</b></dt>
2384 <dd>
2385
2386 <p>Random testing produced case c001 in which the following snipppet</p>
2387
2388 <pre><code>   ok $mi/(@mtime-1) &gt;= 0.75 &amp;&amp; $ai/(@atime-1) &gt;= 0.75 &amp;&amp;
2389              $ss/(@mtime+@atime) &gt;= 0.2;</code></pre>
2390
2391 <p>when processed with these parameters</p>
2392
2393 <pre><code>    --maximum-line-length=20
2394     --nowant-right-space=&#39; / &#39;
2395     --want-break-before=&#39;* /&#39;</code></pre>
2396
2397 <p>produced the following result</p>
2398
2399 <pre><code>    ok $mi
2400       /( @mtime - 1 ) &gt;=
2401       0.75
2402       &amp;&amp; $ai
2403       /( @atime - 1 )
2404       &gt;= 0.75
2405       &amp;&amp; $ss
2406       /( @mtime +
2407           @atime ) &gt;=
2408       0.2;</code></pre>
2409
2410 <p>using &#39;perl -cw&#39; on this snippet gives a syntax error</p>
2411
2412 <pre><code>    syntax error at /tmp/issues.t line 5, near &quot;/( &quot;
2413         (Might be a runaway multi-line // string starting on line 2)</code></pre>
2414
2415 <p>The error is due to perl&#39;s weird parsing rules near a possible indrect object. This is a situation where perltidy must ignore a user spacing and line break request. This should have been done but in this case a flag to prevent this was not being propagated to later stages of formatting. This has been fixed.</p>
2416
2417 <p>20 Apr 2021, 4fbc69a.</p>
2418
2419 </dd>
2420 <dt id="Fix-rare-problem-with--lp--wn"><b>Fix rare problem with -lp -wn</b></dt>
2421 <dd>
2422
2423 <p>Random testing produced case b1114 which gave unstable formatting with these parameters</p>
2424
2425 <pre><code>    --noadd-whitespace
2426     --indent-columns=8
2427     --line-up-parentheses
2428     --maximum-line-length=25
2429     --weld-nested-containers</code></pre>
2430
2431 <p>and this snippet</p>
2432
2433 <pre><code>    is(length(pack(&quot;j&quot;, 0)),
2434         $Config{ivsize});</code></pre>
2435
2436 <p>Fixed 19 Apr 2021, eeeaf09.</p>
2437
2438 </dd>
2439 <dt id="Fix-issue-git-63"><b>Fix issue git#63</b></dt>
2440 <dd>
2441
2442 <p>The following lines produced an error message due to the side comment</p>
2443
2444 <pre><code>    my $fragment = $parser-&gt;    #parse_html_string
2445       parse_balanced_chunk($I);</code></pre>
2446
2447 <p>Fixed 18 Apr 2021, c2030cf.</p>
2448
2449 </dd>
2450 <dt id="Avoid-welding-at-sort-map-grep-paren-calls"><b>Avoid welding at sort/map/grep paren calls</b></dt>
2451 <dd>
2452
2453 <p>Random testing produced several cases of unstable welds in which the inner container something like &#39;sort (&#39;. The problem was that there are special rules which prevent a break following such a paren. The problem was fixed by preventing welds at these locations.</p>
2454
2455 <p>This update fixes cases b1077 b1092 b1093 b1094 b1104 b1105 b1108.</p>
2456
2457 <p>17 Apr 2021, d679b48.</p>
2458
2459 </dd>
2460 <dt id="Fix-issue-git-62"><b>Fix issue git#62</b></dt>
2461 <dd>
2462
2463 <p>This fixes issue git #62. A similar issue for the % operator was fixed. 17 Apr 2021, f80d677.</p>
2464
2465 </dd>
2466 <dt id="Fix-problem-involving--bbx-2--xci--osbr-and-similar--otr-flags"><b>Fix problem involving -bbx=2 -xci -osbr and similar -otr flags</b></dt>
2467 <dd>
2468
2469 <p>Random testing produced case b1100 in which the output style produced by the --opening-token-right flags interfered with counting line-ending commas, and this in turn caused the -bbx flag to turn off the -xci flag. This problem was fixed.</p>
2470
2471 <p>15 Apr 2021, 21ef53b.</p>
2472
2473 </dd>
2474 <dt id="Fix-rare-line-break-problem"><b>Fix rare line break problem</b></dt>
2475 <dd>
2476
2477 <p>Random testing produced case b1097 with this parameter set</p>
2478
2479 <pre><code>    --brace-vertical-tightness-closing=1
2480     --continuation-indentation=8
2481     --indent-columns=10
2482     --maximum-line-length=36</code></pre>
2483
2484 <p>and either this output</p>
2485
2486 <pre><code>          my (@files) = @{
2487                     $args{-files} };</code></pre>
2488
2489 <p>or this output</p>
2490
2491 <pre><code>          my (@files) =
2492                   @{ $args{-files}
2493                   };</code></pre>
2494
2495 <p>The different results were caused by the unusual combination of parameters. The problem was fixed by not allowing the formatter to consider existing breaks at highly stressed locations such as these.</p>
2496
2497 <p>15 Apr 2021, 9f15b9d.</p>
2498
2499 </dd>
2500 <dt id="Fix-problem-parsing-anonymous-subs-with-attribute-lists"><b>Fix problem parsing anonymous subs with attribute lists</b></dt>
2501 <dd>
2502
2503 <p>Random testing produced case b994 with unstable formatting:</p>
2504
2505 <pre><code>    do
2506     sub :
2507     lvalue
2508     {
2509     return;
2510     }</code></pre>
2511
2512 <p>when run with parameters:</p>
2513
2514 <pre><code>    --continuation-indentation=0
2515     --ignore-old-breakpoints
2516     --maximum-line-length=7
2517     --opening-anonymous-sub-brace-on-new-line</code></pre>
2518
2519 <p>The line &#39;sub :&#39; was being correctly parsed but the following opening block brace was not correctly marked as an anonymous sub brace. This fixes cases b994 and b1053.</p>
2520
2521 <p>15 Apr 2021, 84c1123.</p>
2522
2523 </dd>
2524 <dt id="Correct-brace-types-mismarked-by-tokenizer1"><b>Correct brace types mismarked by tokenizer</b></dt>
2525 <dd>
2526
2527 <p>Testing with random parameters produced a case in which a brace following an unknown bareword was marked by the tokenizer as a code block brace rather than a hash brace. This can cause poor formatting. The problem was solved by having the tokenizer send a signal to the formatter if a block type was guessed. The formatter has more information and can fix the problem. This fixes case b1085.</p>
2528
2529 <p>11 Apr 2021, 7d23bf4.</p>
2530
2531 </dd>
2532 <dt id="Unify-coding-for-welded-quotes-and-other-welded-containers"><b>Unify coding for welded quotes and other welded containers</b></dt>
2533 <dd>
2534
2535 <p>Random testing produced some cases where welded quotes were not converging. These were found to be due to the same problem previouly encountered and fixed for normal containers. The problem was fixed by moving the corrected coding to a new common sub.</p>
2536
2537 <p>This update fixes cases b1066 b1067 b1071 b1079 b1080.</p>
2538
2539 <p>10 Apr 2021, 5d73dd5.</p>
2540
2541 </dd>
2542 <dt id="Slight-change-in-weld-length-calculation"><b>Slight change in weld length calculation</b></dt>
2543 <dd>
2544
2545 <p>Random testing produced some cases of instability with some unusual input parameter combinations involving the -wn parameter. This was fixed by revising a line length calculation. This fixes cases b604 and b605.</p>
2546
2547 <p>9 Apr 2021, a25cfaa.</p>
2548
2549 </dd>
2550 <dt id="Improve-treatment-of--vmll-with--wn"><b>Improve treatment of -vmll with -wn</b></dt>
2551 <dd>
2552
2553 <p>Random testing showed a weakness in the treatment of the -vmll flag in combination with the -wn flag. This has been fixed.</p>
2554
2555 <p>This fixes cases b866 b1074 b1075 b1084 b1086 b1087 b1088</p>
2556
2557 <p>8 Apr 2021, a6effa3.</p>
2558
2559 </dd>
2560 <dt id="Merge-weld-rule-6-into-rule-3"><b>Merge weld rule 6 into rule 3</b></dt>
2561 <dd>
2562
2563 <p>One of the welding rules, RULE 6, has been merged into RULE 3 for generality. This rule restricts welding to an opening container followed by a bare word, which can cause instability in some cases. The updated code is less restrictive and fixes some cases recently found with random testing, b1078 b1091.</p>
2564
2565 <p>8 Apr 2021, f28ab55.</p>
2566
2567 </dd>
2568 <dt id="Moved-logic-of-previous-update-to-the-FileWriter-module"><b>Moved logic of previous update to the FileWriter module</b></dt>
2569 <dd>
2570
2571 <p>The previous update regarding blank line generation was not sufficiently general to handle all possible parameter combinations. The problem was solved and simplified by moving the logic to a lower level, in the FileWriter module.</p>
2572
2573 <p>6 Apr 2021, 756e930.</p>
2574
2575 </dd>
2576 <dt id="Fix-problem-with-excess-blank-line-generation-with--blao"><b>Fix problem with excess blank line generation with -blao</b></dt>
2577 <dd>
2578
2579 <p>Random testing produced some cases where excess blank lines could be generated with the parameter -blank-lines-after-opening-block. Case b1073 has the following script</p>
2580
2581 <pre><code>    sub stop {
2582
2583         1;
2584     }</code></pre>
2585
2586 <p>and the following parameters</p>
2587
2588 <pre><code>    --blank-lines-after-opening-block=2
2589     --maximum-consecutive-blank-lines=10
2590     --maximum-line-length=15</code></pre>
2591
2592 <p>When run, blank lines keep getting generated until the maximum is reached. This has been fixed.</p>
2593
2594 <p>6 Apr 2021, 9216298.</p>
2595
2596 </dd>
2597 <dt id="Fix-edge-case-involving--wn-and--lp-or--bbao"><b>Fix edge case involving -wn and -lp or -bbao</b></dt>
2598 <dd>
2599
2600 <p>A change was made to a welding rule involving the -lp option or -wbb=&#39;=&#39;, and very short maximum line lengths. This correctly fixes case b1041. It replaces a fix for this case reported on 2 Apr 2021.</p>
2601
2602 <p>5 Apr 2021.</p>
2603
2604 </dd>
2605 <dt id="Modify-a-condition-for-applying--bbx-2"><b>Modify a condition for applying -bbx=2</b></dt>
2606 <dd>
2607
2608 <p>Random testing produced some edge cases in which formatting with the -bbx=2 flags, in combination with certain other parameters, was not converging. An existing criterion for the -bbx=2 flag to apply is that there be a broken sub-list with at least one line-ending comma. This was updated to also require either a fat comma or one additional line-ending comma. This filters out some problem cases without changing much existing formatting.</p>
2609
2610 <p>This update fixes cases b1068 b1069 b1070 b1072 b1073 b1076.</p>
2611
2612 <p>5 Apr 2021, 16c4591.</p>
2613
2614 </dd>
2615 <dt id="Improve-previous--wn-update"><b>Improve previous -wn update</b></dt>
2616 <dd>
2617
2618 <p>The previous update produced some problems in testing which are corrected with this update.</p>
2619
2620 <p>5 Apr 2021, ffef089.</p>
2621
2622 </dd>
2623 <dt id="Fix-rare-convergence-problem-with--wn"><b>Fix rare convergence problem with -wn</b></dt>
2624 <dd>
2625
2626 <p>Random testing produced some cases in which unusual parameter combinations caused lack of convergence for the -wn flag. The problem was fixed by adjusting a tolerance in the line length calculation.</p>
2627
2628 <p>This fixes cases b1041 b1055.</p>
2629
2630 <p>2 Apr 2021, a8b6259.</p>
2631
2632 </dd>
2633 <dt id="Avoid-conflict-of--bli-and--xci"><b>Avoid conflict of -bli and -xci</b></dt>
2634 <dd>
2635
2636 <p>Random testing produced a case with the combination -bli and -xci which did not converge. This was fixed by turning off -xci for braces under -bli control.</p>
2637
2638 <p>This fixes case b1065.</p>
2639
2640 <p>2 Apr 2021, d20ea80.</p>
2641
2642 </dd>
2643 </dl>
2644
2645 <h1 id="Issues-fixed-after-release-20210111">Issues fixed after release 20210111</h1>
2646
2647 <dl>
2648
2649 <dt id="Avoid-conflict-of--bbp-2-and--xci"><b>Avoid conflict of -bbp=2 and -xci</b></dt>
2650 <dd>
2651
2652 <p>Random testing produced a number of cases of unstable formatting when both -xci and -bbp=2 or similar flags were set. The problem was that -xci can cause one-line blocks to break open, causing the -bbp=2 flag to continually switch formatting. The problem is fixed by locally turning off -xci at containers which do not themselves contain broken containers.</p>
2653
2654 <p>This fixes cases b1033 b1036 b1037 b1038 b1042 b1043 b1044 b1045 b1046 b1047 b1051 b1052 b1061.</p>
2655
2656 <p>30 Mar 2021, 2b05051.</p>
2657
2658 </dd>
2659 <dt id="Fix-rule-for-welding-with-barewords"><b>Fix rule for welding with barewords</b></dt>
2660 <dd>
2661
2662 <p>Random testing produced a case which was not converging due to a rule which avoids welding when a bareword follows. The rule was modified to allow an exception for an existing one-line weld. A non-fatal typo was also discovered and fixed.</p>
2663
2664 <p>This fixes cases b1057 b1064.</p>
2665
2666 <p>29 Mar 2021, d677082.</p>
2667
2668 </dd>
2669 <dt id="Fix-conflict-between--wba-and--opr"><b>Fix conflict between -wba=&#39;||&#39; and -opr</b></dt>
2670 <dd>
2671
2672 <p>Random testing produced a problem with convergence due to a conflict between two parameters for the following code</p>
2673
2674 <pre><code>    my $lxy =
2675       ( @$cx - @$cy ) ||
2676       (
2677         length ( int ( $cx-&gt;[-1] ) ) -
2678         length ( int ( $cy-&gt;[-1] ) ) );</code></pre>
2679
2680 <p>when using these parameters</p>
2681
2682 <pre><code>    --break-after-all-operators
2683     --maximum-line-length=61
2684     --opening-paren-right</code></pre>
2685
2686 <p>Both the &#39;||&#39; and the &#39;(&#39; want to be at the end of a line according to the parameters. The problem is resolved by giving priority to the &#39;||&#39;. This fixes case b1060.</p>
2687
2688 <p>29 Mar 2021, 6921a7d.</p>
2689
2690 </dd>
2691 <dt id="Follow-user-requests-better-to-break-before-operators"><b>Follow user requests better to break before operators</b></dt>
2692 <dd>
2693
2694 <p>Random testing produced some cases in which user requests to break before selected operators were not being followed. For example</p>
2695
2696 <pre><code>    # OLD: perltidy -wbb=&#39;.=&#39;
2697     $value .=
2698       ( grep /\s/, ( $value, $next ) )
2699       ? &quot; $next&quot;
2700       : $next;
2701
2702     # FIXED: perltidy -wbb=&#39;.=&#39;
2703     $value
2704       .= ( grep /\s/, ( $value, $next ) )
2705       ? &quot; $next&quot;
2706       : $next;</code></pre>
2707
2708 <p>This fixes case b1054.</p>
2709
2710 <p>28 Mar 2021, 94f0877.</p>
2711
2712 </dd>
2713 <dt id="Fix-problems-with-combinations-of--iob--lp"><b>Fix problems with combinations of -iob -lp</b></dt>
2714 <dd>
2715
2716 <p>This is an correction to the update of 13 Mar 2021, 71adc77. Random testing produced several additional problems with convergence involving the combination -iob -lp. This update fixes the problem by overriding -iob at some breakpoins which are essential to the -lp parameter.</p>
2717
2718 <p>This update fixes these old cases: b1021 b1023</p>
2719
2720 <p>and these new cases: b1034 b1048 b1049 b1050 b1056 b1058</p>
2721
2722 <p>27 Mar 2021, cc94623.</p>
2723
2724 </dd>
2725 <dt id="Add-flag--lpxl-s-to-provide-control-over--lp-formatting"><b>Add flag -lpxl=s to provide control over -lp formatting</b></dt>
2726 <dd>
2727
2728 <p>The flag -lpxl=s provides control over which containers get -lp formatting. A shortcut flag -lfp is also added for limiting -lp to simple function calls.</p>
2729
2730 <p>Updated 25 Mar 2021, bfc00fp.</p>
2731
2732 </dd>
2733 <dt id="Fix-error-message-for-multiple-conflicting-specifications-in--wnxl"><b>Fix error message for multiple conflicting specifications in -wnxl</b></dt>
2734 <dd>
2735
2736 <p>There was an error in the coding for an error message which checks for conflicting requests in the -wnxl parameter.</p>
2737
2738 <p>Fixed 21 Mar 2021, 2ef97a2.</p>
2739
2740 </dd>
2741 <dt id="Fix-issue-git-57-Warn_count-was-not-initialized"><b>Fix issue git #57, Warn_count was not initialized</b></dt>
2742 <dd>
2743
2744 <p>This update fixes issue git #57, in which a warning flag was not getting zeroed on each new call to perltidy.</p>
2745
2746 <p>19 Mar 2021, b6d296a.</p>
2747
2748 </dd>
2749 <dt id="Fix-rare-problem-with-combination--lp--wn--naws"><b>Fix rare problem with combination -lp -wn -naws</b></dt>
2750 <dd>
2751
2752 <p>This update fixes case b1032 by includeing lines starting with &#39;if&#39;, &#39;or&#39;, and || among the stable breakpoints for welding when -lp -naws flags are also set.</p>
2753
2754 <p>This update also modifies update 7a6be43 of 16 Mar 2021 to exclude list items when checking token lengths. This reduces changes to existing formatting while still fixing the problem in case b1031.</p>
2755
2756 <p>18 Mar 2021, 6200034.</p>
2757
2758 </dd>
2759 <dt id="Fix-definition-of-list-within-list-for--bbx-flags"><b>Fix definition of list within list for -bbx flags</b></dt>
2760 <dd>
2761
2762 <p>Testing produced a blinking state involving a -bbx=2 flag with an unusual combination of other parameters. The problem was traced to the definition of a list containing another list being too restrictive. This update fixes case 1024.</p>
2763
2764 <p>17 Mar 2021, 7f5da0a.</p>
2765
2766 </dd>
2767 <dt id="Fix-problem-with--xci-and-long-tokens"><b>Fix problem with -xci and long tokens</b></dt>
2768 <dd>
2769
2770 <p>Testing produced an unstable situation involving the -xci flag and tokens which exceed the maximum line length. This fix identifies this situation and locally deactivates the -xci flag. This fixes case b1031.</p>
2771
2772 <p>16 Mar 2021, 7a6be43.</p>
2773
2774 </dd>
2775 <dt id="Fix-error-in-parsing-use-statement-curly-brace"><b>Fix error in parsing use statement curly brace</b></dt>
2776 <dd>
2777
2778 <p>Testing with random parameters produced some cases where the -xci option was not producing stable results when the maximum line length was set to a very small value. The problem was traced to the tokenizer misparsing a hash brace of a use statement as a code block type. This influences the value of continuation indentation within the braces. The problem was fixed.</p>
2779
2780 <p>This fixes cases b1022 b1025 b1026 b1027 b1028 b1029 b1030</p>
2781
2782 <p>16 Mar 2021, 6371be2.</p>
2783
2784 </dd>
2785 <dt id="Fix-problems-with-combinations-of--iob--lp--wn--dws--naws"><b>Fix problems with combinations of -iob -lp -wn -dws -naws</b></dt>
2786 <dd>
2787
2788 <p>Testing with random parameters produced some situation where the parameter -iob interfered with convergence when parameters -lp and/or -wn were also set. The combination -wn -lp -dws -naws also produced some non-converging states in testing. This update fixes these issues.</p>
2789
2790 <p>The following cases are fixed: b1019 b1020 b1021 b1023</p>
2791
2792 <p>13 Mar 2021, 71adc77.</p>
2793
2794 </dd>
2795 <dt id="Simplify-sub-weld_nested_containers"><b>Simplify sub weld_nested_containers</b></dt>
2796 <dd>
2797
2798 <p>This update consolidates a number of specialized rules for welding into fewer, simpler rules which accomplish the same effect.</p>
2799
2800 <p>These cases are fixed with this update: b186 b520 b872 b937 b996 b997 b1002 b1003 b1004 b1005 b1006 b1013 b1014</p>
2801
2802 <p>There are no current open issues with the weld logic.</p>
2803
2804 <p>10 Mar 2021, cf3ed23.</p>
2805
2806 </dd>
2807 <dt id="Adjust-line-length-tolerance-for-welding"><b>Adjust line length tolerance for welding</b></dt>
2808 <dd>
2809
2810 <p>A minor tolerance adjustment was needed to fix some edge welding cases.</p>
2811
2812 <p>This fixes cases b995 b998 b1000 b1001 b1007 b1008 b1009 b1010 b1011 b1012 b1016 b1017 b1018</p>
2813
2814 <p>7 Mar 2021, b9166ca.</p>
2815
2816 </dd>
2817 <dt id="Fix-problem-with--vtc-n-and-outdented-long-lines"><b>Fix problem with -vtc=n and outdented long lines</b></dt>
2818 <dd>
2819
2820 <p>Random testing produced an issue with -vtc=1 and an outdented long line. The parameters for b999 are</p>
2821
2822 <pre><code>    --maximum-line-length=75
2823     --paren-vertical-tightness-closing=1</code></pre>
2824
2825 <p>File &#39;b999.in&#39; state 1 is</p>
2826
2827 <pre><code>                while ( $line =~
2828     s/^([^\t]*)(\t+)/$1.(&quot; &quot; x ((length($2)&lt;&lt;3)-(length($1)&amp;7)))/e
2829                   )</code></pre>
2830
2831 <p>and state 2 is</p>
2832
2833 <pre><code>                while ( $line =~
2834     s/^([^\t]*)(\t+)/$1.(&quot; &quot; x ((length($2)&lt;&lt;3)-(length($1)&amp;7)))/e)</code></pre>
2835
2836 <p>The problem was fixed by turning off caching for outdented long lines. This fixes case b999.</p>
2837
2838 <p>7 Mar 2021, 3da7e41.</p>
2839
2840 </dd>
2841 <dt id="Fix-problem-with-combination--lp-and--wbb"><b>Fix problem with combination -lp and -wbb=&#39;=&#39;</b></dt>
2842 <dd>
2843
2844 <p>Random testing produced case b932 in which the combination -lp and -wbb=&#39;=&#39; was not stable.</p>
2845
2846 <p>File &#39;b932.par&#39; is:</p>
2847
2848 <pre><code>    --line-up-parentheses
2849     --maximum-line-length=51
2850     --want-break-before=&#39;=&#39;</code></pre>
2851
2852 <p>File &#39;b932.in&#39; in the desired state is:</p>
2853
2854 <pre><code>    my @parts
2855       = decompose( &#39;(\s+|/|\!|=)&#39;,
2856                    $line, undef, 1, undef, &#39;[&quot;\&#39;]&#39; );</code></pre>
2857
2858 <p>The alternate state is</p>
2859
2860 <pre><code>    my @parts = decompose( &#39;(\s+|/|\!|=)&#39;,
2861                      $line, undef, 1, undef, &#39;[&quot;\&#39;]&#39; );</code></pre>
2862
2863 <p>The problem was that the -lp code which set a line break at the equals did not check the -wba flag setting.</p>
2864
2865 <p>This update fixes case b932.</p>
2866
2867 <p>7 Mar 2021, 63129c3.</p>
2868
2869 </dd>
2870 <dt id="Fix-edge-formatting-cases-with-parameter--bbx-2"><b>Fix edge formatting cases with parameter -bbx=2</b></dt>
2871 <dd>
2872
2873 <p>Random testing produced some cases where formatting with parameters of the form --break-before-..=2 can lead to unstable final states. The problem lies in the definition of a broken list. The problem is fixed by defining a broken list for this particular flag to be a list with at least one non-terminal line-ending comma. This insures that the list will remain broken on subsequent iterations. This fixes cases b789 and b938.</p>
2874
2875 <p>6 Mar 2021, 360d669.</p>
2876
2877 </dd>
2878 <dt id="Add-flag--fpva---function-paren-vertical-alignment"><b>Add flag -fpva, --function-paren-vertical-alignment</b></dt>
2879 <dd>
2880
2881 <p>A flag -fpva, --function-paren-vertical-alignment, is added to prevent vertical alignment of function parens when the -sfp flag is used. This is on by default, so that existing formatting remains unchanged unless the user requests that vertical alignment not occur with -nfpva.</p>
2882
2883 <p>5 Mar 2021, 312be4c.</p>
2884
2885 </dd>
2886 <dt id="Fix-for-issue-git-53-do-not-align-spaced-function-parens"><b>Fix for issue git #53, do not align spaced function parens</b></dt>
2887 <dd>
2888
2889 <p>Introducing a space before a function call paren had a side effect of allowing the vertical aligner to align the parens, as in the example.</p>
2890
2891 <pre><code>    # OLD and NEW, default without -sfp:
2892     log_something_with_long_function( &#39;This is a log message.&#39;, 2 );
2893     Coro::AnyEvent::sleep( 3, 4 );
2894
2895     # OLD: perltidy -sfp
2896     log_something_with_long_function ( &#39;This is a log message.&#39;, 2 );
2897     Coro::AnyEvent::sleep            ( 3, 4 );
2898
2899     # NEW: perltidy -sfp
2900     log_something_with_long_function ( &#39;This is a log message.&#39;, 2 );
2901     Coro::AnyEvent::sleep ( 3, 4 );</code></pre>
2902
2903 <p>This update changes the default to not do this vertical alignment. This should have been the default but this side-effect was missed when the -sfp parameter was added. Note that parens following keywords are likewise not vertically aligned.</p>
2904
2905 <p>5 Mar 2021, 00431bf.</p>
2906
2907 </dd>
2908 <dt id="Fix-issue-git-54-involving--bbp-n-and--bbpi-n"><b>Fix issue git#54 involving -bbp=n and -bbpi=n</b></dt>
2909 <dd>
2910
2911 <p>In this issue, different results were obtained depending upon the existence of a comma in a list. To fix this, the definition of a list was adjusted from requiring one or more commas to requiring either a fat comma or a comma.</p>
2912
2913 <p>At the same time, a known problem involving the combination -lp -bbp=n -bbpi=n was fixed. This fixes cases b826 b909 b989.</p>
2914
2915 <p>4 Mar 2021, 872d4b4.</p>
2916
2917 </dd>
2918 <dt id="Fix-several-minor-weld-issues"><b>Fix several minor weld issues</b></dt>
2919 <dd>
2920
2921 <p>Some edge cases for the welding parameter -wn have been fixed. There are no other currently known weld issues. Some debug code for welding has been left in the code for possible future use.</p>
2922
2923 <p>This fixes cases b109 b110 b520 b756 b901 b937 b965 b982 b988 b991 b992 b993</p>
2924
2925 <p>3 Mar 2021, cfef087.</p>
2926
2927 </dd>
2928 <dt id="Update-tokenizer-recognition-of-indirect-object"><b>Update tokenizer recognition of indirect object</b></dt>
2929 <dd>
2930
2931 <p>This is the parameter file b990.pro: --noadd-whitespace --continuation-indentation=0 --maximum-line-length=7 --space-terminal-semicolon</p>
2932
2933 <p>Applying perltidy -pro=b990.pro to the following snippet gave two states</p>
2934
2935 <pre><code>    # State 1
2936     print
2937     H;
2938
2939     # State 2
2940     print H
2941     ;</code></pre>
2942
2943 <p>The tokenizer was alternately parsing &#39;H&#39; as either possble indirect object, &#39;Z&#39;, or indirect object, &#39;Y&#39;. Two fixes were tested. The first was to modify the tokenizer to recognize a &#39;;&#39; as well as a space as a direct object terminator. An alternative fix is to not allowing a break before type &#39;Y&#39; so that the tokenizer kept parsing as type &#39;Y&#39;. Both fixes work, but the latter fix would change existing formatting by the -extrude option, so the first fix was used. With this fix, the stable state is &#39;State 1&#39; above.</p>
2944
2945 <p>This update is a generalization of the update <a href="#Fixed-blinker-related-to-line-break-at-indirect-object">&quot;Fixed blinker related to line break at indirect object&quot;</a> of 16 Jan 2021.</p>
2946
2947 <p>This fixes case b990. 1 Mar 2021, 49cd66f.</p>
2948
2949 </dd>
2950 <dt id="Do-not-start-a-batch-with-a-blank-token"><b>Do not start a batch with a blank token</b></dt>
2951 <dd>
2952
2953 <p>Perltidy does final formatting in discrete batches of tokens, where a batch is a continuous section of the total token list. A batch begins a new line and will be broken into one or more lines. If a batch starts with a blank token it will simply be skipped on on output. However, some rare problems have been found in random testing which can occur if a batch starts with a blank. An example is case b984 which has the following parameters:</p>
2954
2955 <pre><code>        # this is file &#39;b984.pro&#39;
2956         --block-brace-vertical-tightness=2
2957         --indent-columns=10
2958         --maximum-line-length=27
2959         --outdent-keywords
2960         --variable-maximum-line-length
2961
2962           # OLD: perltidy -pro=b984.pro
2963           unless (
2964                     exists $self-&gt;{
2965                               &#39;accession_number&#39;} )
2966           {         return &quot;unknown&quot;;
2967           }
2968
2969           # NEW: perltidy -pro=b984.pro
2970           unless (
2971                     exists $self-&gt;{
2972                               &#39;accession_number&#39;} )
2973           {       return &quot;unknown&quot;;
2974           }</code></pre>
2975
2976 <p>Both look OK, but the OLD version did not outdent the keyword &#39;return&#39; as requested with the -okw flag.</p>
2977
2978 <p>This update fixes cases b149 b888 b984 b985 b986 b987.</p>
2979
2980 <p>28 Feb 2021, 8aaf599.</p>
2981
2982 </dd>
2983 <dt id="Avoid-double-spaces-in--csc-text-output"><b>Avoid double spaces in -csc text output</b></dt>
2984 <dd>
2985
2986 <p>Random testing produced some rare cases where two spaces could occur in -csc text. This happened when there were multiple lines and the formatter placed a leading blank in one of the continuation lines as padding. This has been fixed.</p>
2987
2988 <p>For example</p>
2989
2990 <pre><code>    while (
2991         &lt;&gt;;
2992       )
2993     {
2994        ...
2995     } ## end while ( &lt;&gt;; )</code></pre>
2996
2997 <p>Previously, the last line had an extra space after the &#39;;&#39;</p>
2998
2999 <pre><code>    } ## end while ( &lt;&gt;;  )</code></pre>
3000
3001 <p>Another example</p>
3002
3003 <pre><code>    while (
3004         do {
3005             { package DB; @a = caller( $i++ ) }
3006         }
3007       )
3008     {
3009       ...
3010     } ## end while ( do { { package DB...}})</code></pre>
3011
3012 <p>Previously the last line had an extra space between the opening braces:</p>
3013
3014 <pre><code>    } ## end while ( do {  { package DB...}})</code></pre>
3015
3016 <p>27 Feb 2021, b22e891.</p>
3017
3018 </dd>
3019 <dt id="Remove-control-of-debug-flag--fll"><b>Remove control of debug flag -fll</b></dt>
3020 <dd>
3021
3022 <p>Random testing produced an unstable state when a debug flag, -nfll, was set. The only time it is appropriate to set this flag is if the -extrude option is set, so a check was added to verify this. This fixes case b935.</p>
3023
3024 <p>27 Feb 2021, 9155b3d.</p>
3025
3026 </dd>
3027 <dt id="Restrict-previous-update-to-just--vmll"><b>Restrict previous update to just -vmll</b></dt>
3028 <dd>
3029
3030 <p>The previous update was found to occasionally needlessly change existing formatting with very long long lines. So it is restricted to just when -vmll is set. For example, it is ok to keep the long quote following the opening paren in the following case.</p>
3031
3032 <pre><code>  # perltidy -gnu
3033   ok( &quot;got to the end without dying (note without DEBUGGING passing this test means nothing)&quot;
3034     );</code></pre>
3035
3036 <p>26 Feb 2021, 2b88464.</p>
3037
3038 </dd>
3039 <dt id="Add-a-gap-calculation-in-line-length-tests-with--vmll"><b>Add a gap calculation in line length tests with -vmll</b></dt>
3040 <dd>
3041
3042 <p>This fixes case b965. The -vmll flag can produce gaps in lines which need to be included in weld line length estimates.</p>
3043
3044 <p>26 Feb 2021, a643cf2.</p>
3045
3046 </dd>
3047 <dt id="Update-rule-for-spacing-paren-after-constant-function"><b>Update rule for spacing paren after constant function</b></dt>
3048 <dd>
3049
3050 <p>Random testing produced an unstable state for the following snippet (case b934)</p>
3051
3052 <pre><code>        sub pi();
3053         if (
3054             $t &gt;
3055             pi( )
3056               )</code></pre>
3057
3058 <p>when run with these parameters:</p>
3059
3060 <pre><code>  --continuation-indentation=6
3061   --maximum-line-length=17
3062   --paren-vertical-tightness-closing=2</code></pre>
3063
3064 <p>The formatting was stable without the first line, which declares &#39;pi&#39; to be a constant sub. The problem was fixed by updating a regex to treat the spacing of a paren following a sub the same for the two token types, &#39;U&#39; or &#39;C&#39; (constant function).</p>
3065
3066 <p>This fixes case b934, 12bfdfe.</p>
3067
3068 <p>26 Feb 2021.</p>
3069
3070 </dd>
3071 <dt id="Improve-line-length-test-for-the--vtc-2-option"><b>Improve line length test for the -vtc=2 option</b></dt>
3072 <dd>
3073
3074 <p>This is a small change to the update of 13 Feb 2021, f79a4f1. Random testing produced additional blinking states caused by the combination of -vtc=2 and -vmll flag, plus several others. The problem was that a line length check in the vertical aligner was being skipped as an optimization if it didn&#39;t appear necessary. The unusual properties of the -vmll flag require that the check always be done.</p>
3075
3076 <p>This fixes cases b656 b862 b971 b972.</p>
3077
3078 <p>26 Feb 2021, 80107e0.</p>
3079
3080 </dd>
3081 <dt id="Improve-one-line-block-length-tests"><b>Improve one-line block length tests</b></dt>
3082 <dd>
3083
3084 <p>Some oscillating states produced in random parameter tests were traced to problems with forming one-line blocks. A more precise length test was added to fix this.</p>
3085
3086 <p>This fixes cases b562 b563 b574 b777 b778 b924 b936 b975 b976 b983.</p>
3087
3088 <p>In the process of fixing this issue, a glitch was discovered in the previous coding of the -bl (braces-left) flag that caused somewhat random results for block types sort/map/grep/eval. The problem was a conflict between the logic for forming one-line blocks and the logic for applying the -bl flag. Usually, -bl formatting was not applied to these block types, but occasionally it was. To minimize changes in existing formatting, in the new version the -bl flag is not applied to these block types. A future flag could be added to give user control over which of these block types are under -bl control.</p>
3089
3090 <p>25 Feb 2021, 92bec8d.</p>
3091
3092 </dd>
3093 <dt id="Add-tolerance-to-one-line-block-length-tests"><b>Add tolerance to one-line block length tests</b></dt>
3094 <dd>
3095
3096 <p>Testing with random input parameters produced some cases in which a stable solution could not be found due to attempts to form one-line blocks near the end of a long line. The problem was fixed by adding a small tolerance to the line length test. This does not change existing formatting.</p>
3097
3098 <p>This fixes cases b069 b070 b077 b078.</p>
3099
3100 <p>21 Feb 2021, 0b97b94.</p>
3101
3102 </dd>
3103 <dt id="Restrict--bom-at-cuddled-method-calls"><b>Restrict -bom at cuddled method calls</b></dt>
3104 <dd>
3105
3106 <p>The -bom flag tries to keep old breakpoints at lines beginning with &#39;-&gt;&#39; and also with some lines beginning with &#39;)-&gt;&#39;. These latter lines can lead to blinking states in cases where the opening paren is on the previous line. To fix this, a restriction was added that the line difference between the opening and closing parens should be more than 1.</p>
3107
3108 <p>This fixes case b977.</p>
3109
3110 <p>21 Feb 2021, 28114e9.</p>
3111
3112 </dd>
3113 <dt id="Add-weld-rule-to-avoid-conflict-between--wn-and--bom"><b>Add weld rule to avoid conflict between -wn and -bom</b></dt>
3114 <dd>
3115
3116 <p>Testing with ramdom input parameters produced states which were oscillating because of a conflict between the -wn and -bom parameters. The problem was resolved by giving the -bom parameter priority over -wn.</p>
3117
3118 <p>These cases are fixed with this update: b966 b973</p>
3119
3120 <p>20 Feb 2021.</p>
3121
3122 </dd>
3123 <dt id="Limit-the-value-of--ci-n-to-that-of--i-n-when--xci-is-set"><b>Limit the value of -ci=n to that of -i=n when -xci is set</b></dt>
3124 <dd>
3125
3126 <p>Testing with random input parameters produced a number of oscillating states which had both parameter -xci as well as a value of -ci=n which exceeded the value of -i=n. To correct this, perltidy will silently reduce the -ci value to the -i value when -xci is also set. This should not change existing formatting because a value of -ci greater than -i would not normally be used in practice.</p>
3127
3128 <p>These cases are fixed with this update: b707 b770 b912 b920 b930 b933 b939 b940 b941 b942 b978 b974 b979 b980 b981</p>
3129
3130 <p>20 Feb 2021, c16c5ee.</p>
3131
3132 </dd>
3133 <dt id="Modify-length-tolerance-for-welding-to-qw-lists"><b>Modify length tolerance for welding to qw lists</b></dt>
3134 <dd>
3135
3136 <p>Several cases of alternating states were produced in random testing which were caused by line length limits being reached when welding to qw lists. This was fixed by adding a small tolerance to line length tests.</p>
3137
3138 <p>This fixes cases b654 b655 b943 b944 b967 b968 b969 b970.</p>
3139
3140 <p>19 Feb 2021, 0baafc8.</p>
3141
3142 </dd>
3143 <dt id="Modify-space-rule-between-binary-plus-or-minus-and-a-bareword"><b>Modify space rule between binary plus or minus and a bareword</b></dt>
3144 <dd>
3145
3146 <p>The update of 13 Feb 2021, cf414fe, has been modified to be less restrictive. Space between a binary plus and minus and a bareword may now be removed in some cases where no tokenization ambiguity exists. 18 Feb 2021, a8564c8.</p>
3147
3148 </dd>
3149 <dt id="Do-not-apply--xci-if-it-would-put-tokens-beyond-the-maximum-line-length"><b>Do not apply -xci if it would put tokens beyond the maximum line length</b></dt>
3150 <dd>
3151
3152 <p>This update fixes cases b899 b935. 17 Feb 2021, b955a7c.</p>
3153
3154 </dd>
3155 <dt id="Do-not-weld-to-a-hash-brace"><b>Do not weld to a hash brace</b></dt>
3156 <dd>
3157
3158 <p>The reason is that it has a very strong bond strength to the next token, so a line break after it may not work. Previously we allowed welding to something like &#39;@{&#39; but even that caused blinking states (cases b751, b779).</p>
3159
3160 <p>This will not change much existing code. This update fixes cases b751 b779.</p>
3161
3162 <p>16 Feb 2021, eb2f4e7.</p>
3163
3164 </dd>
3165 <dt id="Avoid-line-breaks-after-token-type-G"><b>Avoid line breaks after token type &#39;G&#39;</b></dt>
3166 <dd>
3167
3168 <p>Random testing with very short maximum line lengths produced some blinking states which were traced to the tokenizer alternately parsed an unknown bareword as type &#39;w&#39; or type &#39;G&#39;, depending on whether or not an opening block brace immediately followed on the same line. To fix this, a rule was added which prevents a line break between a type &#39;G&#39; token and an opening code block brace.</p>
3169
3170 <p>This update fixes these cases: b900 b902 b928 b929</p>
3171
3172 <p>15 Feb 2021, f005a95.</p>
3173
3174 </dd>
3175 <dt id="Restrict-breaking-at-old-uncontained-commas"><b>Restrict breaking at old uncontained commas</b></dt>
3176 <dd>
3177
3178 <p>Random testing with very short maximum line lengths produced some blinking states which were traced to duplicating old comma breakpoints which were not really good breakpoints. A patch was made to be more selective.</p>
3179
3180 <p>These cases are fixed with this update: b610 b757 b931</p>
3181
3182 <p>15 Feb 2021, 98b41a0.</p>
3183
3184 </dd>
3185 <dt id="Modify-line-length-test-for-the--vtc-2-option"><b>Modify line length test for the -vtc=2 option</b></dt>
3186 <dd>
3187
3188 <p>The line length test which was added Feb 13 2021 turns out to be more restrictive than necessary. A modification was made to only apply it if a new one-line block would be formed. This prevents it from needlessly changing existing formatting.</p>
3189
3190 <p>The following cases were re-activated after this update: b654 b655 b656 b862</p>
3191
3192 <p>15 Feb 2021, 4673fdd.</p>
3193
3194 </dd>
3195 <dt id="Use-increased-line-length-tolerance-if-ci-exceeds-i"><b>Use increased line length tolerance if ci exceeds i</b></dt>
3196 <dd>
3197
3198 <p>In testing perltidy with random input parameters, some blinking states occurred when the value of -ci was significantly larger than the value of -i. (In actual practice, -ci is not normally set greater than -i). This update adds a tolerance to line length tests which avoids this problem. This fixes the following cases</p>
3199
3200 <p>b775 b776 b826 b908 b910 b911 b923 b925 b926 b927</p>
3201
3202 <p>14 Feb 2021, 8451f2f.</p>
3203
3204 </dd>
3205 <dt id="Keep-space-between-binary-plus-or-minus-and-a-bareword"><b>Keep space between binary plus or minus and a bareword</b></dt>
3206 <dd>
3207
3208 <p>This update makes a space between a binary + or - and a bareword an essential whitespace. Otherwise, they may be converted into unary + or - on the next pass, which can lead to blinking states. Fixes cases b660 b670 b780 b781 b787 b788 b790.</p>
3209
3210 <p>13 Feb 2021, cf414fe.</p>
3211
3212 </dd>
3213 <dt id="Prevent-breaks-after-unary-plus-and-minus"><b>Prevent breaks after unary plus and minus</b></dt>
3214 <dd>
3215
3216 <p>Some alternating states were produced when extremely maximum line lengths forced a break after a unary plus or minus. Fixes cases b670 b790.</p>
3217
3218 <p>13 Feb 2021, cf414fe.</p>
3219
3220 </dd>
3221 <dt id="Add-line-length-test-for-the--vtc-2-option"><b>Add line length test for the -vtc=2 option</b></dt>
3222 <dd>
3223
3224 <p>Random testing produced a number of cases of blinking states which were caused when the -vtc=2 flag caused the vertical aligner to combine lines which exceeded the allowable line length. These long lines were then getting reduced in size on every other iteration. A line length test was added in the vertical aligner to prevent this. This fixes these cases:</p>
3225
3226 <p>b654 b655 b656 b657 b761 b762 b763 b764 b765 b766 b767 b768 b769 b862 b904 b905 b906 b907 b913 b914 b915 b916 b917 b918 b919</p>
3227
3228 <p>13 Feb 2021, f79a4f1.</p>
3229
3230 </dd>
3231 <dt id="Define-left-side-bond-strengths-for-unary-plus-and-minus"><b>Define left side bond strengths for unary plus and minus</b></dt>
3232 <dd>
3233
3234 <p>Random testing produced a blinking state which was traced to the unary plus not having a defined strength in the line break algorithm. This was fixed by setting it to be the same as the left strength of a plus. This fixes case b511. 12 Feb 2021, 58a7895.</p>
3235
3236 </dd>
3237 <dt id="Fix-problem-with-breaking-at-an-sign"><b>Fix problem with breaking at an = sign</b></dt>
3238 <dd>
3239
3240 <p>Random testing produced some blinking cases which were related to detecting an old good breakpoint at an equals. If the user requested that a break be done before an equals, and the input script had a break after an equals, then that break should not have been marked as a good existing break point before a keyword. This update fixes cases b434 b903.</p>
3241
3242 <p>11 Feb 2021, f9a8543.</p>
3243
3244 </dd>
3245 <dt id="Fix-conflict-of--kbl-0-and-essential-space-after-cut"><b>Fix conflict of -kbl=0 and essential space after =cut</b></dt>
3246 <dd>
3247
3248 <p>Random testing produced a case where a blank line after an =cut was alternately being deleted and added due to a conflict with the flag setting -keep-old-blank-lines=0. This was resolved by giving prioritiy to the essential blank line after the =cut line.</p>
3249
3250 <p>This fixes case b860. 11 Feb 2021, 8c13609.</p>
3251
3252 </dd>
3253 <dt id="Do-not-break-one-line-block-at-here-target"><b>Do not break one-line block at here target</b></dt>
3254 <dd>
3255
3256 <p>A blinking state produced by random testing was traced to a line of coding which which unnecessarily prevented one-line blocks from being formed when a here-target was encountered. This has been fixed.</p>
3257
3258 <p>For example, the code block in the following contains a here target and was being broken into two lines:</p>
3259
3260 <pre><code>    unless ($INC{$file}) {
3261         die &lt;&lt;&quot;END_DIE&quot; }</code></pre>
3262
3263 <p>These will now be output with the blocks intact, like this</p>
3264
3265 <pre><code>    unless ($INC{$file}) { die &lt;&lt;&quot;END_DIE&quot; }</code></pre>
3266
3267 <p>This fixes case b523. 11 Feb 2021, 6d5bb74.</p>
3268
3269 </dd>
3270 <dt id="Skip-processing--kgb-flags-in-lists-or-if--maximum-consecutive-blank-lines-0"><b>Skip processing -kgb* flags in lists or if -maximum-consecutive-blank-lines=0</b></dt>
3271 <dd>
3272
3273 <p>Random testing produced an alternating state which was caused by -kgb flags being active on keywords which were in a list rather than a code block. A check was added to prevent this. Also, the -kgb* flags have no effect if no blank lines can be output, so a check was added for this situation. This fixes case b760.</p>
3274
3275 <p>10 Feb 2021, 177fc3a.</p>
3276
3277 </dd>
3278 <dt id="Modify-tolerance-in-testing-for-welds"><b>Modify tolerance in testing for welds</b></dt>
3279 <dd>
3280
3281 <p>Random testing with unusual parameters produced some blinking weld states which were fixed by modifying a tolerance used in a line length test. The following cases were fixed with this update:</p>
3282
3283 <p>b746 b748 b749 b750 b752 b753 b754 b755 b756 b758 b759 b771 b772 b773 b774 b782 b783 b784 b785 b786</p>
3284
3285 <p>9 Feb 2021, a4609ac.</p>
3286
3287 </dd>
3288 <dt id="Modified-rule-for-breaking-lines-at-old-commas"><b>Modified rule for breaking lines at old commas</b></dt>
3289 <dd>
3290
3291 <p>Random testing produced some blinking cases resulting from the treatment of old line breaks at commas not contained within containers. The following cases were fixed with this update:</p>
3292
3293 <p>b064 b065 b068 b210 b747</p>
3294
3295 <p>This change has no effect on scripts with normal parameter values. 9 Feb 2021, 5c23661.</p>
3296
3297 </dd>
3298 <dt id="Restrict-references-to-old-line-breaks"><b>Restrict references to old line breaks</b></dt>
3299 <dd>
3300
3301 <p>A number of cases of blinking states were traced to code which biased the breaking of long lines to existing breaks. This was fixed by restricting this coding to just use old comma line break points.</p>
3302
3303 <p>The following cases were fixed with this update:</p>
3304
3305 <p>b193 b194 b195 b197 b198 b199 b216 b217 b218 b219 b220 b221 b244 b245 b246 b247 b249 b251 b252 b253 b254 b256 b257 b258 b259 b260 b261 b262 b263 b264 b265 b266 b268 b269 b270 b271 b272 b274 b275 b278 b280 b281 b283 b285 b288 b291 b295 b296 b297 b299 b302 b304 b305 b307 b310 b311 b312 b313 b314 b315 b316 b317 b318 b319 b320 b321 b322 b323 b324 b325 b326 b327 b329 b330 b331 b332 b333 b334 b335 b336 b337 b338 b339 b340 b341 b342 b343 b344 b345 b346 b347 b348 b349</p>
3306
3307 <p>8 Feb 2021, 66be455.</p>
3308
3309 </dd>
3310 <dt id="Fix-rare-problem-involving-interaction-of--olbn-n-and--wn-flags"><b>Fix rare problem involving interaction of -olbn=n and -wn flags</b></dt>
3311 <dd>
3312
3313 <p>Random testing revealed a rare alternating state which could occur when both flags --one-line-block-nesting=n and --weld-nested-containers are set, and the maximum line length is set very low. The problem was fixed by ignoring the first flag at welded tokens. This should not have any effect on scripts with realistic parameter values.</p>
3314
3315 <p>The following case was fixed with this update: b690.</p>
3316
3317 <p>6 Feb 2021, 3e96930.</p>
3318
3319 </dd>
3320 <dt id="add-rule-to-avoid-welding-at-some-barewords"><b>add rule to avoid welding at some barewords</b></dt>
3321 <dd>
3322
3323 <p>A rule was added to prevent certain rare blinking states involving welding. The rule is that if an opening container is immediately followed by a bareword which is unknown, a weld will be avoided.</p>
3324
3325 <p>The following cases were fixed with this update: b611 b626.</p>
3326
3327 <p>6 Feb 2021, 6b1f44a</p>
3328
3329 </dd>
3330 <dt id="further-simplify--bbxi-n-implementation"><b>further simplify -bbxi=n implementation</b></dt>
3331 <dd>
3332
3333 <p>This update adds a new variable which indicates if a container is permanently broken due to a side comment or blank line. This helps reduce the number of cases where the -bbxi=n flag cannot be applied. Another change was to always apply the -bbx=n flag, even if the -bbxi=n flag cannot be applied. These two flags now operate almost exactly as in previous versions but without the blinking problem. The only difference is that now the -bbxi=n flag with n&gt;0 will revert to n=0 for some short containers which might not be broken open.</p>
3334
3335 </dd>
3336 <dt id="reset--bbxi-2-to--bbxi-0-if--lp-is-set-to-avoid-blinking-states"><b>reset -bbxi=2 to -bbxi=0 if -lp is set to avoid blinking states</b></dt>
3337 <dd>
3338
3339 <p>The options of the form bbxi=2, such as break-before-paren-and-indent=2, have been found to cause blinking states if the -lp flag is set. Both of these options are fairly rare. To correct this the -bbxi=2 flag is now reset to -bbxi=0 if the -lp flag is set. Note that -bbxi=2 and -bbxi=0 give the same formatting result with the common setting -ci=4 and -i=4.</p>
3340
3341 <p>The following cases were fixed with this update:</p>
3342
3343 <p>b396 b397 b398 b429 b435 b457 b502 b503 b504 b505 b538 b540 b542 b617 b618 b619 b620 b621</p>
3344
3345 <p>3 Feb 2021, 67ab0ef.</p>
3346
3347 </dd>
3348 <dt id="rewrite-sub-break_before_list_opening_containers"><b>rewrite sub break_before_list_opening_containers</b></dt>
3349 <dd>
3350
3351 <p>sub break_before_list_opening_containers was rewritten to reduce the chance of producing alternating states.</p>
3352
3353 <p>The following cases were fixed with this update:</p>
3354
3355 <p>b030 b032 b455 b456 b458 b459 b460 b461 b462 b536 b622 b651 b652 b653 b708 b709 b710 b713 b714 b719 b723 b724 b725 b726 b727 b729 b731 b733 b735 b736 b737 b738 b739 b740 b743 b744</p>
3356
3357 <p>3 Feb 2021, 5083ab9.</p>
3358
3359 </dd>
3360 <dt id="redefine-list-to-have-at-least-one-internal-comma"><b>redefine list to have at least one internal comma</b></dt>
3361 <dd>
3362
3363 <p>Random testing produced some blinking states which could be fixed by changing the definition of a list, for formatting purposes, to have one or more interior commas rather than simply one or more commas. The difference is that something with a single terminal comma, like &#39;( $x, )&#39;, is no longer classified as a list. This makes no difference except when perltidy is stress tested with unusual parameters.</p>
3364
3365 <p>The following cases were fixed with this update:</p>
3366
3367 <p>b116 b119 b122 b174 b179 b187 b361 b369 b370 b372 b376 b427 b428 b448 b449 b450 b451 b452 b453 b469 b473 b474 b475 b476 b477 b479 b480 b481 b482 b497 b552 b553 b554 b558 b559 b634 b637 b642 b644 b645 b647 b650 b661 b662 b663 b664 b666 b677 b685 b688 b698 b699 b700 b702 b703 b704 b711 b712 b715 b716 b717 b718 b721 b730 b734 b741 b742</p>
3368
3369 <p>1 Feb 2021, 35078f7.</p>
3370
3371 </dd>
3372 <dt id="rewrite-and-combine-coding-for--bbx-n-and--bbxi-n"><b>rewrite and combine coding for -bbx=n and -bbxi=n</b></dt>
3373 <dd>
3374
3375 <p>Random testing produced a large number of blinking states involving parameters such as --break-before-parens=n and --break-before-parens-and-indent=n and similar pairs. The problem was traced to the fact that the former parameter was implemented late in the pipeline whereas the latter parameter was implemented early in the pipeline. Normally there was no problem, but in some extreme cases, often involving very short maximum line lengths, this could produce alternating output states. The problem was resolved by combining the implementation of both flags in a single new sub to avoid any inconsistencies. The following cases were fixed with this update:</p>
3376
3377 <p>b018 b066 b071 b079 b090 b105 b146 b149 b158 b160 b161 b163 b164 b166 b167 b169 b170 b171 b172 b178 b185 b190 b192 b203 b206 b222 b223 b224 b237 b359 b362 b377 b379 b381 b382 b389 b395 b407 b408 b409 b410 b411 b412 b414 b417 b418 b419 b421 b433 b438 b443 b444 b478 b483 b484 b486 b490 b492 b493 b494 b496 b506 b507 b517 b521 b522 b524 b525 b535 b537 b539 b541 b543 b546 b550 b551 b555 b564 b566 b567 b569 b570 b572 b573 b575 b576 b577 b578 b579 b580 b582 b586 b587 b588 b589 b590 b591 b592 b593 b603 b607 b609 b613 b615 b616 b623 b624 b630 b635 b636 b638 b639 b640 b641 b643 b646 b648 b649 b658 b659 b665 b667 b668 b669 b671 b672 b673 b674 b675 b676 b678 b679 b680 b681 b682 b683 b684 b686 b687 b689 b691 b692 b693 b694 b695 b696 b697 b701 b705 b706 b720 b722 b728 b732 b745</p>
3378
3379 <p>31 Jan 2021, 10e8bfd.</p>
3380
3381 </dd>
3382 <dt id="adjust-line-length-and-token-count-tolerances-for--wn"><b>adjust line length and token count tolerances for -wn</b></dt>
3383 <dd>
3384
3385 <p>Most remaining edge cases of blinking states involving the -wn parameter have been fixed by adjusting some tolerances in sub weld_nested_containers. The following cases are fixed with this update:</p>
3386
3387 <p>b156 b157 b186 b196 b454 b520 b527 b530 b532 b533 b534 b612 b614 b625 b627</p>
3388
3389 <p>This update has no effect for realistic parameter settings.</p>
3390
3391 <p>30 Jan 2021, d359a60.</p>
3392
3393 </dd>
3394 <dt id="fix-additional-edge-blinker-cases-involving--wn"><b>fix additional edge blinker cases involving -wn</b></dt>
3395 <dd>
3396
3397 <p>Some blinking cases produced in random testing were traced to welding in very short lines (length = 20 for example) in which a weld was made to a square bracket containing just a single parameter, so that it had no good internal breaking points. A rule was added to avoid welding to a square bracket not containing any commas. The following cases were fixed with the update:</p>
3398
3399 <p>b002 b003 b005 b006 b007 b009 b010 b014 b015 b017 b020 b111 b112 b113 b124 b126 b128 b151 b153 b439 b606</p>
3400
3401 <p>29 Jan 2021, 33f1f2b.</p>
3402
3403 </dd>
3404 <dt id="fix-additional-edge-blinker-cases-involving--wn1"><b>fix additional edge blinker cases involving -wn</b></dt>
3405 <dd>
3406
3407 <p>Random testing produced some blinking states which were traced to the precision of a line length test. In sub weld_nested_containers, the test</p>
3408
3409 <pre><code>    $do_not_weld ||= $excess_length_to_K-&gt;($Kinner_opening) &gt; 0;</code></pre>
3410
3411 <p>was changed to allow a 1 character margin of error:</p>
3412
3413 <pre><code>    $do_not_weld ||= $excess_length_to_K-&gt;($Kinner_opening) &gt;= 0;</code></pre>
3414
3415 <p>The following cases were fixed with this update:</p>
3416
3417 <p>b025 b075 b091 b109 b110 b152 b154 b155 b162 b168 b176 b422 b423 b424 b425 b426 b565</p>
3418
3419 <p>29 Jan 2021, 33f1f2b.</p>
3420
3421 </dd>
3422 <dt id="fix-some-edge-blinker-cases-involving--wn"><b>fix some edge blinker cases involving -wn</b></dt>
3423 <dd>
3424
3425 <p>Random testing produced some blinking states which were eliminated by a simplification of the definition of a one_line_weld in sub weld_nested_containers. The following cases were fixed with this update:</p>
3426
3427 <p>b131 b134 b136 b205 b233 b238 b284 b350 b352 b358 b385 b487 b604 b605</p>
3428
3429 <p>29 Jan 2021, 33f1f2b.</p>
3430
3431 </dd>
3432 <dt id="fix-some-edge-blinker-cases-involving--bbxi-n-esp.-with--boc"><b>fix some edge blinker cases involving -bbxi=n esp. with -boc</b></dt>
3433 <dd>
3434
3435 <p>The following cases were fixed with this update:</p>
3436
3437 <p>b041 b182 b184 b366 b367 b368 b370 b371 b382 b420 b432 b438 b464 b466 b467 b468 b500 b501 b508 b509 b510 b512 b513 b514 b515 b516 b526 b528 b529 b531 b544 b545 b547 b548 b549 b556 b557 b568 b571 b581 b583 b584 b585 b594 b595 b596 b597 b598 b599 b600 b601 b602 b608 b041 b182 b184 b355 b356 b366 b367 b368 b371 b420 b432 b464 b465 b466 b467 b468 b500 b501 b508 b509 b510 b512 b513 b514 b515 b516 b526 b528 b529 b531 b544 b545 b547 b548 b549 b556 b557 b568 b571 b581 b583 b584</p>
3438
3439 <p>28 Jan 2021.</p>
3440
3441 </dd>
3442 <dt id="fix-problem-with-combination--cab-2-and-bbhbi-n"><b>fix problem with combination -cab=2 and bbhbi=n</b></dt>
3443 <dd>
3444
3445 <p>Random testing produced a number of cases in which the combination -cab=2 and bbhbi=n and similar flags were in conflict, causing alternating states. This was fixed by not changing ci for containers which can fit entirely on one line, which is what -cab=2 says to do. The following cases were fixed with this update:</p>
3446
3447 <p>b046 b061 b081 b084 b089 b093 b130 b133 b135 b138 b142 b145 b147 b150 b165 b173 b191 b211 b294 b309 b360 b363 b364 b365 b373 b386 b387 b388 b392 b437 b440 b472 b488 b489</p>
3448
3449 <p>27 Jan 2021, 6d710de.</p>
3450
3451 </dd>
3452 <dt id="fix-problem-with--freeze-whitespace"><b>fix problem with -freeze-whitespace</b></dt>
3453 <dd>
3454
3455 <p>Random testing produced a case in which the --freeze-whitespace flag (which is mainly useful for testing) could cause a blank space which kept increasing. The problem was caused by the &quot;vertical tightness&quot; mechanism. Turning it off when the -freeze-whitespace-flag is on fixed the problem. The following cases were fixed with this update:</p>
3456
3457 <p>b037 b038 b043 b059 b060 b067 b072 b215 b225 b267 b273 b276 b279 b282 b289 b292 b300 b303 b354 b374 b375 b383 b384 b402 b403 b404 b405 b436 b441 b445 b446 b471 b485 b498 b499</p>
3458
3459 <p>27 Jan 2021, 6d710de.</p>
3460
3461 </dd>
3462 <dt id="Avoid-blinking-states-associated-with--bbpi-and-similar-flags"><b>Avoid blinking states associated with -bbpi and similar flags</b></dt>
3463 <dd>
3464
3465 <p>Random testing with extreme parameter values revealed blinking states associated with the -bbpi and related flags. The problem was that continuation indentation was sometimes being added according to the flag but the lists were not actually being broken. After this was fixed the following cases ran correctly:</p>
3466
3467 <p>b024 b035 b036 b040 b042 b047 b049 b050 b051 b052 b053 b054 b057 b062 b063 b073 b074 b076 b080 b083 b085 b086 b087 b088 b102 b103 b104 b106 b107 b108 b115 b118 b121 b123 b125 b127 b132 b137 b139 b140 b141 b143 b144 b148 b159 b175 b177 b180 b181 b188 b189 b200 b201 b202 b204 b207 b212 b213 b214 b226 b227 b228 b229 b230 b232 b239 b240 b241 b243 b248 b250 b255 b277 b286 b287 b290 b293 b298 b301 b306 b308 b328 b351 b353 b357 b378 b380 b390 b391 b393 b394 b399 b400 b401 b406 b413 b415 b416 b430 b431 b442 b447 b463 b470 b491 b495</p>
3468
3469 <p>27 Jan 2021, 96144a3.</p>
3470
3471 </dd>
3472 <dt id="Revise-coding-for-the---freeze-whitespace-option"><b>Revise coding for the --freeze-whitespace option</b></dt>
3473 <dd>
3474
3475 <p>Random testing produced some blinking states which were traced to an incorrect implementation of the <b>--freeze-whitespace</b> option (which is mainly useful in stress testing perltidy). A related flag, --add-whitespace is involved. This update corrects these problems. Test cases include b057, b183, b242. 24 Jan 2021, 9956a57.</p>
3476
3477 </dd>
3478 <dt id="Fix-for-issue-git-51-closing-qw-paren-not-outdented-when--ndnl-is-set"><b>Fix for issue git #51, closing qw paren not outdented when -ndnl is set</b></dt>
3479 <dd>
3480
3481 <p>The problem is that a bare closing qw paren was not being outdented if the flag &#39;-nodelete-old-newlines is set. For example</p>
3482
3483 <pre><code>    # OLD (OK, outdented): perltidy -ci=4 -xci
3484     {
3485         modules =&gt; [
3486             qw(
3487                 JSON
3488             )
3489         ],
3490     }
3491
3492
3493     # OLD (indented) : perltidy -ndnl -ci=4 -xci
3494     {
3495         modules =&gt; [
3496             qw(
3497                 JSON
3498                 )
3499         ],
3500     }
3501
3502     # FIXED: perltidy -ndnl -ci=4 -xci
3503     {
3504         modules =&gt; [
3505             qw(
3506                 JSON
3507             )
3508         ],
3509     }</code></pre>
3510
3511 <p>The problem happened because the -ndnl flag forces each line to be written immediately, so the next line (which needs to be checked in this case) was not available when the outdent decision had to be made. A patch to work around this was added 24 Jan 2021, 52996fb.</p>
3512
3513 </dd>
3514 <dt id="Some-issues-with-the--lp-option"><b>Some issues with the -lp option</b></dt>
3515 <dd>
3516
3517 <p>Random testing revealed some problems involving the <b>-lp</b> option which are fixed with this update.</p>
3518
3519 <p>The problem is illustrated with the following snippet</p>
3520
3521 <pre><code>    # perltidy -lp
3522     Alien::FillOutTemplate(
3523                 &quot;$main::libdir/to-$main::desttype/$main::filetype/spec&quot;,
3524                 &quot;$workdir/$fields{NAME}-$fields{VERSION}-$fields{RELEASE}.spec&quot;,
3525                 %fields
3526     );</code></pre>
3527
3528 <p>which alternately formats to this form</p>
3529
3530 <pre><code>    # perltidy -lp
3531     Alien::FillOutTemplate(
3532                 &quot;$main::libdir/to-$main::desttype/$main::filetype/spec&quot;,
3533                 &quot;$workdir/$fields{NAME}-$fields{VERSION}-$fields{RELEASE}.spec&quot;,
3534                 %fields );</code></pre>
3535
3536 <p>when formatted with the single parameter <b>-lp</b>. A number of similar examples were found in testing. The problem was traced to the treatment of the space which perltidy tentatively adds wherever there is a newline, just in case the formatted output has different line breaks. The problem was that the indentation level of these spaces was being set as the level of the next token rather than the previous token. Normally the indentation level of a space has no effect, but the <b>-lp</b> option does use it and this caused the problem. This was fixed 23 Jan 2021, edc7878.</p>
3537
3538 </dd>
3539 <dt id="added-rule-for--wn-do-not-weld-to-a-hash-brace"><b>added rule for -wn, do not weld to a hash brace</b></dt>
3540 <dd>
3541
3542 <p>In random testing, the following two alternating states</p>
3543
3544 <pre><code>    # State 1
3545     {
3546         if ( defined
3547         ($symbol_table{$direccion}) )
3548     }
3549
3550     # State 2
3551     {
3552         if (defined (
3553                 $symbol_table{
3554                     $direccion}
3555             )
3556         )
3557     }</code></pre>
3558
3559 <p>were occurring with the following particular parameter set</p>
3560
3561 <pre><code>    --weld-nested-containers
3562     --maximum-line-length=40
3563     --continuation-indentation=7
3564     --paren-tightness=2
3565     --extended-continuation-indentation</code></pre>
3566
3567 <p>The problem was traced to welding to the opening hash brace. A rule was added to prevent this, and testing with a large body of code showed that it did not significantly change existing formatting. With this change, the above snippet formats in the stable state</p>
3568
3569 <pre><code>    {
3570         if (defined(
3571             $symbol_table{$direccion}
3572         ))
3573     }</code></pre>
3574
3575 <p>20 Jan 2021, 4021436.</p>
3576
3577 </dd>
3578 <dt id="Do-not-let--kgb-option-delete-essential-blank-after-cut"><b>Do not let -kgb option delete essential blank after =cut</b></dt>
3579 <dd>
3580
3581 <p>A blinking state was found in random testing for the following snippet</p>
3582
3583 <pre><code>    =head1 TODO
3584
3585     handle UNIMARC encodings
3586
3587     =cut
3588
3589     use strict;
3590     use warnings;</code></pre>
3591
3592 <p>when run with the following parameters</p>
3593
3594 <pre><code>    --keyword-group-blanks-size=&#39;2.8&#39;
3595     --keyword-group-blanks-before=0</code></pre>
3596
3597 <p>The space after the =cut was alternately being added as an essential blank which is required by pod utilities, and then deleted by these parameters. This was fixed 17 Jan 2021, b9a5f5d.</p>
3598
3599 </dd>
3600 <dt id="Turn-off--boc-flag-if--iob-is-set"><b>Turn off -boc flag if -iob is set</b></dt>
3601 <dd>
3602
3603 <p>In random testing, the cause of a blinker was traced to both flags --ignore-old-breakpoints and --break-at-old-comma-breakpoints being set. There is a warning message but the -boc flag was not actually being turned off. This was fixed 17 Jan 2021, b9a5f5d.</p>
3604
3605 </dd>
3606 <dt id="Modified-spacing-rule-for-token-type-Y"><b>Modified spacing rule for token type Y</b></dt>
3607 <dd>
3608
3609 <p>A space following a token type &#39;Y&#39; (filehandle) should not be removed. Otherwise it might be converted into type &#39;Z&#39; (possible filehandle). If that were to happen, the space could not be added back automatically in later formatting, so the user would have to do it by hand. This fix prevents this from happening. 17 Jan 2021, bef9a83.</p>
3610
3611 </dd>
3612 <dt id="Fixed-blinker-related-to-line-break-at-indirect-object"><b>Fixed blinker related to line break at indirect object</b></dt>
3613 <dd>
3614
3615 <p>In random testing a blinker was reduced to the following snippet</p>
3616
3617 <pre><code>    {
3618              print FILE
3619               GD::Barcode
3620               -&gt;new();
3621     }</code></pre>
3622
3623 <p>which switched to the following state on each iteration</p>
3624
3625 <pre><code>    {
3626              print FILE GD::Barcode
3627               -&gt;new();
3628     }</code></pre>
3629
3630 <p>with the following parameters</p>
3631
3632 <pre><code>    --maximum-line-length=20
3633     --indent-columns=9
3634     --continuation-indentation=1</code></pre>
3635
3636 <p>The problem was that the token &#39;FILE&#39; was either parsed as type &#39;Y&#39; or &#39;Z&#39; depending on the existence of a subsequent space. These have different line break rules, causing a blinker. The problem was fixed by modifying the tokenizer to consider a newline to be a space. Updated 16 Jan 2021, d40cca9.</p>
3637
3638 </dd>
3639 <dt id="Turn-off--bli-if--bar-is-set"><b>Turn off -bli if -bar is set</b></dt>
3640 <dd>
3641
3642 <p>A conflict arises if both <b>-bli</b> and <b>-bar</b> are set. In this case a warning message is given and <b>-bli</b> is turned off. Updated 15 Jan 2021, ef69531.</p>
3643
3644 </dd>
3645 <dt id="Fixed-blinker-related-to-large--ci-short-line-length-and--bbsbi-2--bbsb-1"><b>Fixed blinker related to large -ci, short line length and -bbsbi=2 -bbsb=1</b></dt>
3646 <dd>
3647
3648 <p>A blinking state was discovered in testing between the following two states</p>
3649
3650 <pre><code>    my$table=
3651          [[1,2,3],[2,4,6],[3,6,9],
3652          ];
3653
3654     my$table=
3655         [[1,2,3],[2,4,6],[3,6,9],];</code></pre>
3656
3657 <p>with these parameters</p>
3658
3659 <pre><code>    --continuation-indentation=5
3660     --maximum-line-length=31
3661     --break-before-square-bracket-and-indent=2
3662     --break-before-square-bracket=1
3663     --noadd-whitespace</code></pre>
3664
3665 <p>The problem was found to be caused by the -bbsb parameters causing the indentation level of the first square bracket to change depending upon whether the term was broken on input or not. Two fixes would correct this. One is to turn off the option if the -ci=n value exceeds the -i=n value. The other is to require a broken container to span at least three lines before turning this option on. The latter option was made to sub &#39;adjust_container_indentation&#39;. With this change the snippet remains stable at the second state above. Fixed 14 Jan 2021, 5c793a1.</p>
3666
3667 </dd>
3668 <dt id="Fixed-blinker-related-to-large--ci-short-line-length-and--wn"><b>Fixed blinker related to large -ci, short line length and -wn</b></dt>
3669 <dd>
3670
3671 <p>In random testing with convergence a &#39;blinker&#39; (oscillating states) was found for the following script</p>
3672
3673 <pre><code>    sub _prompt {
3674
3675           print $_[0];
3676           return (
3677                 readline
3678                        (*{$_[1]})!~
3679                        /^q/i)
3680                  ; # Return false if user types &#39;q&#39;
3681
3682     }</code></pre>
3683
3684 <p>with the following specific parameters:</p>
3685
3686 <pre><code>    --maximum-line-length=32
3687     --indent-columns=6
3688     --continuation-indentation=7
3689     --weld-nested-containers
3690     --extended-continuation-indentation
3691     --noadd-whitespace</code></pre>
3692
3693 <p>The other state was</p>
3694
3695 <pre><code>    sub _prompt {
3696
3697           print $_[0];
3698           return (
3699                 readline(
3700                       *{
3701                             $_
3702                                    [
3703                                    1
3704                                    ]
3705                       }
3706                 )!~/^q/i
3707                  )
3708                  ; # Return false if user types &#39;q&#39;
3709
3710     }</code></pre>
3711
3712 <p>All of the listed parameters are required to cause this, but the main cause is the very large continuation indentation and short line length. Welding was being turned on and off in this case. Normally welding is not done if all containers are on a single line, but an exception was made to detect a situation like this and keep the welded string together. Updated 13 Jan 2021, 5c793a1.</p>
3713
3714 </dd>
3715 <dt id="Fixed-incorrect-guess-of-division-vs-pattern"><b>Fixed incorrect guess of division vs pattern</b></dt>
3716 <dd>
3717
3718 <p>A syntax error was produced in random testing when perltidy was fed the following line:</p>
3719
3720 <pre><code>    sub _DR () { pi2 /360 } sub _RD () { 360 /pi2 }</code></pre>
3721
3722 <p>The bareword &#39;pi2&#39; was not recognized and the text between the two slashes was a taken as a possible pattern argument in a parenless call to pi2. Two fixes were made to fix this. Perltidy looks for &#39;pi&#39; but not &#39;pi2&#39;, so the first fix was to expand its table to include all variations of &#39;pi&#39; in Trig.pm. Second, the fact that the first slash was followed by a number should have tipped the guess to favor division, so this was fixed. As it was, a backup spacing rule was used, which favored a pattern.</p>
3723
3724 <p>The formatted result is now</p>
3725
3726 <pre><code>    sub _DR () { pi2 / 360 }
3727     sub _RD () { 360 / pi2 }</code></pre>
3728
3729 <p>This update was made 13 Jan 2021, a50ecf8.</p>
3730
3731 </dd>
3732 <dt id="Correct-formula-for-estimating-line-length-with--wn-option"><b>Correct formula for estimating line length with -wn option</b></dt>
3733 <dd>
3734
3735 <p>A formula used to estimating maximum line length when the -wn option is set was missing a term for continuation indentation. No actual changes in formatting have been seen. This update made 12 Jan 2021.</p>
3736
3737 </dd>
3738 <dt id="Fixed-unusual-blinker-related-to-large--ci-and--mft-n"><b>Fixed unusual blinker related to large -ci and -mft=n</b></dt>
3739 <dd>
3740
3741 <p>The following blinker was found in random testing. The following statement (with @j starting at level 0)</p>
3742
3743 <pre><code>    @j = ( $x, $y, $z );</code></pre>
3744
3745 <p>run with the following parameters</p>
3746
3747 <pre><code>    --indent-columns=5
3748     --continuation-indentation=7
3749     --maximum-line-length=20
3750     --break-before-paren-and-indent=2
3751     --break-before-paren=2
3752     --maximum-fields-per-table=4</code></pre>
3753
3754 <p>caused an oscillation between two states. An unusual feature which contributed to the problem is the very large ci value. This is fixed in a patch made 12 Jan 2021, 9a97dba.</p>
3755
3756 </dd>
3757 </dl>
3758
3759 <h1 id="Issues-fixed-after-release-20201207">Issues fixed after release 20201207</h1>
3760
3761 <dl>
3762
3763 <dt id="Improve-indentation-of-multiline-qw-quotes-when--xci-flag-is-set"><b>Improve indentation of multiline qw quotes when -xci flag is set</b></dt>
3764 <dd>
3765
3766 <p>The indentation of multiline qw quotes runs into problems when there is nesting, as in the following.</p>
3767
3768 <pre><code>    # OLD: perltidy -xci -ci=4
3769     for my $feep (
3770         qw{
3771         pwage      pwchange   pwclass    pwcomment
3772         pwexpire   pwgecos    pwpasswd   pwquota
3773         }
3774         )</code></pre>
3775
3776 <p>The problem is that multiline qw quotes do not get the same indentation treatment as lists.</p>
3777
3778 <p>This update fixes this in the following circumstances:</p>
3779
3780 <pre><code>  - the leading qw( and trailing ) are on separate lines
3781   - the closing token is one of ) } ] &gt;
3782   - the -xci flag is set</code></pre>
3783
3784 <p>The above example becomes</p>
3785
3786 <pre><code>    # NEW: perltidy -xci -ci=4
3787     for my $feep (
3788         qw{
3789             pwage      pwchange   pwclass    pwcomment
3790             pwexpire   pwgecos    pwpasswd   pwquota
3791         }
3792         )</code></pre>
3793
3794 <p>The reason that the -xci flag is required is to minimize unexpected changes to existing scripts. The extra indentation is removed if the -wn flag is also given, so both old and new versions with -wn give</p>
3795
3796 <pre><code>    # OLD and NEW: perltidy -wn -xci -ci=4
3797     for my $feep ( qw{
3798         pwage      pwchange   pwclass    pwcomment
3799         pwexpire   pwgecos    pwpasswd   pwquota
3800     } )</code></pre>
3801
3802 <p>This update added 8 Jan 2021, 474cfa8.</p>
3803
3804 </dd>
3805 <dt id="Improve-alignment-of-leading-equals-in-rare-situation"><b>Improve alignment of leading equals in rare situation</b></dt>
3806 <dd>
3807
3808 <p>A rare case in which a vertical alignment opportunity of leading equals was missed has been fixed. This involved lines with additional varying alignment tokens, such as &#39;unless&#39; and second &#39;=&#39; in lines 1-3 below. In this example lines 4 and 5 were not &#39;looking&#39; backwards to align their leading equals.</p>
3809
3810 <pre><code>    # OLD:
3811     $them = &#39;localhost&#39; unless ( $them = shift );
3812     $cmd  = &#39;!print&#39;    unless ( $cmd  = shift );
3813     $port = 2345        unless ( $port = shift );
3814     $saddr = &#39;S n a4 x8&#39;;
3815     $SIG{&#39;INT&#39;} = &#39;dokill&#39;;
3816
3817     # NEW
3818     $them       = &#39;localhost&#39; unless ( $them = shift );
3819     $cmd        = &#39;!print&#39;    unless ( $cmd  = shift );
3820     $port       = 2345        unless ( $port = shift );
3821     $saddr      = &#39;S n a4 x8&#39;;
3822     $SIG{&#39;INT&#39;} = &#39;dokill&#39;;</code></pre>
3823
3824 <p>Fixed 5 Jan 2021, 9244678.</p>
3825
3826 </dd>
3827 <dt id="Moved-previous-patch-to-a-better-location"><b>Moved previous patch to a better location</b></dt>
3828 <dd>
3829
3830 <p>The previous patch was moved to a location where it only applies if there is a side comment on the line with a closing token. This minimizes changes to other side comment locations.</p>
3831
3832 </dd>
3833 <dt id="Further-improvement-in-rules-for-forgetting-last-side-comment-location"><b>Further improvement in rules for forgetting last side comment location</b></dt>
3834 <dd>
3835
3836 <p>The code for forgetting the last side comment location was rewritten to improve formatting in some edge cases. The update also fixes a very rare problem discovered during testing and illustrated with the following snippet. The problem occurs for the particular combination of parameters -sct -act=2 and when a closing paren has a side comment:</p>
3837
3838 <pre><code>    OLD: perltidy -sct -act=2
3839     foreach $line (
3840         [0, 1, 2], [3, 4, 5], [6, 7, 8],    # rows
3841         [0, 3, 6], [1, 4, 7], [2, 5, 8],    # columns
3842         [0, 4, 8], [2, 4, 6])                                     # diagonals
3843
3844     NEW: perltidy -sct -act=2
3845     foreach $line (
3846         [0, 1, 2], [3, 4, 5], [6, 7, 8],    # rows
3847         [0, 3, 6], [1, 4, 7], [2, 5, 8],    # columns
3848         [0, 4, 8], [2, 4, 6])    # diagonals</code></pre>
3849
3850 <p>In the old version the last side comment was aligned before the closing paren was attached to the previous line, causing the final side comment to be far to the right. A patch in the new version just places it at the default location. This is the best than can be done for now, but is preferable to the old formatting. 3 Jan 2021, e57d8db.</p>
3851
3852 </dd>
3853 <dt id="Improve-rule-for-forgetting-last-side-comment-location"><b>Improve rule for forgetting last side comment location</b></dt>
3854 <dd>
3855
3856 <p>The code which aligns side comments remembers the most recent side comment and in some cases tries to start aligning at that column for later side comments. Sometimes the old side comment column was being remembered too long, causing occasional poor formatting and causing a noticeable and unexpected drift of side comment locations to the right. The rule for forgetting the previous side comment column has been modified to reduce this problem. The new rule is essentially to forget the previous side comment location at a new side comment with different indentation level or significant number of lines without side comments (about 12). The previous implementation forgetting changes in indentation level across code blocks only. Below is an example where the old method gets into trouble and the new method is ok:</p>
3857
3858 <pre><code>        # OLD:
3859         foreach my $r (@$array) {
3860             $Dat{Data}{ uc $r-&gt;[0] } = join( &quot;;&quot;, @$r );    # store all info
3861             my $name = $Dat{GivenName}{ uc $r-&gt;[0] } || $r-&gt;[1];
3862
3863             # pass array as ad-hoc string, mark missing values
3864             $Dat{Data}{ uc $r-&gt;[0] } = join(
3865                 &quot;;&quot;,
3866                 (
3867                     uc $r-&gt;[0], uc $name,                   # symbol, name
3868                     $r-&gt;[2],    $r-&gt;[3], $r-&gt;[4],           # price, date, time
3869                     $r-&gt;[5],    $r-&gt;[6],                    # change, %change
3870                     $r-&gt;[7],    &quot;-&quot;, &quot;-&quot;, &quot;-&quot;,    # vol, avg vol, bid,ask
3871                     $r-&gt;[8],               $r-&gt;[9],     # previous, open
3872                     &quot;$r-&gt;[10] - $r-&gt;[11]&quot;, $r-&gt;[12],    # day range,year range,
3873                     &quot;-&quot;,                   &quot;-&quot;, &quot;-&quot;, &quot;-&quot;, &quot;-&quot;
3874                 )
3875             );                                          # eps,p/e,div,yld,cap
3876         }</code></pre>
3877
3878 <p>The second side comment is at a deeper indentation level but was not being forgotten, causing line length limits to interfere with later alignment. The new rule gives a better result:</p>
3879
3880 <pre><code>        # NEW:
3881         foreach my $r (@$array) {
3882             $Dat{Data}{ uc $r-&gt;[0] } = join( &quot;;&quot;, @$r );    # store all info
3883             my $name = $Dat{GivenName}{ uc $r-&gt;[0] } || $r-&gt;[1];
3884
3885             # pass array as ad-hoc string, mark missing values
3886             $Dat{Data}{ uc $r-&gt;[0] } = join(
3887                 &quot;;&quot;,
3888                 (
3889                     uc $r-&gt;[0], uc $name,               # symbol, name
3890                     $r-&gt;[2],    $r-&gt;[3], $r-&gt;[4],       # price, date, time
3891                     $r-&gt;[5],    $r-&gt;[6],                # change, %change
3892                     $r-&gt;[7],    &quot;-&quot;, &quot;-&quot;, &quot;-&quot;,          # vol, avg vol, bid,ask
3893                     $r-&gt;[8],               $r-&gt;[9],     # previous, open
3894                     &quot;$r-&gt;[10] - $r-&gt;[11]&quot;, $r-&gt;[12],    # day range,year range,
3895                     &quot;-&quot;,                   &quot;-&quot;, &quot;-&quot;, &quot;-&quot;, &quot;-&quot;
3896                 )
3897             );    # eps,p/e,div,yld,cap
3898         }</code></pre>
3899
3900 <p>The following exampel shows an unexpected alignment in the cascade of trailing comments which are aligned but slowly separating from their closing containers:</p>
3901
3902 <pre><code>    # OLD:
3903     {
3904         $a = [
3905             Cascade    =&gt; $menu_cb,
3906             -menuitems =&gt; [
3907                 [ Checkbutton =&gt; &#39;Oil checked&#39;, -variable =&gt; \$OIL ],
3908                 [
3909                     Button   =&gt; &#39;See current values&#39;,
3910                     -command =&gt; [
3911                         \&amp;see_vars, $TOP,
3912
3913                     ],    # end see_vars
3914                 ],        # end button
3915             ],            # end checkbutton menuitems
3916         ];                # end checkbuttons cascade
3917     }</code></pre>
3918
3919 <p>This was caused by forgetting side comments only across code block changes. The new result is more reasonable:</p>
3920
3921 <pre><code>    # NEW:
3922     {
3923         $a = [
3924             Cascade    =&gt; $menu_cb,
3925             -menuitems =&gt; [
3926                 [ Checkbutton =&gt; &#39;Oil checked&#39;, -variable =&gt; \$OIL ],
3927                 [
3928                     Button   =&gt; &#39;See current values&#39;,
3929                     -command =&gt; [
3930                         \&amp;see_vars, $TOP,
3931
3932                     ],    # end see_vars
3933                 ],    # end button
3934             ],    # end checkbutton menuitems
3935         ];    # end checkbuttons cascade
3936     }</code></pre>
3937
3938 <p>This change will cause occasional differences in side comment locations from previous versions but overall it gives fewer unexpected results so it is a worthwhile change. 29-Dec-2020, 76993f4.</p>
3939
3940 </dd>
3941 <dt id="Fixed-very-minor-inconsistency-in-redefining-lists-after-prune-step"><b>Fixed very minor inconsistency in redefining lists after prune step</b></dt>
3942 <dd>
3943
3944 <p>In rare cases it is necessary to update the type of lists, and this influences vertical alignment. This update fixes a minor inconsistency in doing this. In some rare cases with complex list elements vertical alignment can be improved. 27 Dec, 2020, 751faec.</p>
3945
3946 <pre><code>            # OLD
3947             return join( &#39;&#39;,
3948                 $pre,   &#39;&lt;IMG &#39;,   $iconsizes{$alt} || &#39;&#39;,
3949                 $align, &#39;BORDER=&#39;, $nav_border,
3950                 &#39; ALT=&quot;&#39;, $alt,        &quot;\&quot;\n&quot;,
3951                 &#39; SRC=&quot;&#39;, $ICONSERVER, &quot;/$icon&quot;,
3952                 &#39;&quot;&gt;&#39; );
3953
3954             # NEW
3955             return join( &#39;&#39;,
3956                 $pre,     &#39;&lt;IMG &#39;,     $iconsizes{$alt} || &#39;&#39;,
3957                 $align,   &#39;BORDER=&#39;,   $nav_border,
3958                 &#39; ALT=&quot;&#39;, $alt,        &quot;\&quot;\n&quot;,
3959                 &#39; SRC=&quot;&#39;, $ICONSERVER, &quot;/$icon&quot;,
3960                 &#39;&quot;&gt;&#39; );</code></pre>
3961
3962 </dd>
3963 <dt id="Improved-vertical-alignment-of-some-edge-cases"><b>Improved vertical alignment of some edge cases</b></dt>
3964 <dd>
3965
3966 <p>The existing rules for aligning two lines with very different lengths were rejecting some good alignments, such as the first line of numbers in the example below:</p>
3967
3968 <pre><code>    # OLD:
3969     @gg_3 = (
3970         [
3971             0.0, 1.360755E-2, 9.569446E-4, 9.569446E-4,
3972             1.043498E-3, 1.043498E-3
3973         ],
3974         [
3975             9.569446E-4, 9.569446E-4, 0.0, 7.065964E-5,
3976             1.422811E-4, 1.422811E-4
3977         ],
3978         ...
3979     );
3980
3981     # NEW:
3982     @gg_3 = (
3983         [
3984             0.0,         1.360755E-2, 9.569446E-4, 9.569446E-4,
3985             1.043498E-3, 1.043498E-3
3986         ],
3987         [
3988             9.569446E-4, 9.569446E-4, 0.0, 7.065964E-5,
3989             1.422811E-4, 1.422811E-4
3990         ],
3991         ...
3992     );</code></pre>
3993
3994 <p>The rule in sub &#39;two_line_pad&#39; was updated to allow alignment of any lists if the patterns match exactly (all numbers in this case). Updated 27-Dec-2020, 035d2b7.</p>
3995
3996 </dd>
3997 <dt id="Avoid--lp-style-formatting-of-lists-containing-multiline-qw-quotes"><b>Avoid -lp style formatting of lists containing multiline qw quotes</b></dt>
3998 <dd>
3999
4000 <p>The -lp formatting style often does not work well when lists contain multiline qw quotes. This update avoids this problem by not formatting such lists with the -lp style. For example,</p>
4001
4002 <pre><code>    # OLD, perltidy -gnu
4003     @EXPORT = (
4004         qw(
4005           i Re Im rho theta arg
4006           sqrt log ln
4007           log10 logn cbrt root
4008           cplx cplxe
4009           ),
4010         @trig,
4011               );
4012
4013
4014     # NEW, perltidy -gnu
4015     @EXPORT = (
4016         qw(
4017           i Re Im rho theta arg
4018           sqrt log ln
4019           log10 logn cbrt root
4020           cplx cplxe
4021         ),
4022         @trig,
4023     );</code></pre>
4024
4025 <p>27-Dec-2020, 948c9bd.</p>
4026
4027 </dd>
4028 <dt id="improve-formatting-of-multiline-qw"><b>improve formatting of multiline qw</b></dt>
4029 <dd>
4030
4031 <p>This update adds a sequence numbering system for multiline qw quotes. In the perltidy tokenizer normal container pair types, like { }, (), [], are given unique serial numbers which are used as keys to data structures. qw quoted lists do not get serial numbers by the tokenizer, so this update creates a separate serial number scheme for them to correct this problem. One formatting problem that this solves is that of preventing the closing token of a multiline quote from being outdented more than the opening token. This is a general formatting rule which should be followed. Without a sequence number, the closing qw token could not lookup its corresponding opening indentation so it had to resort to a default, breaking the rule, as in the following:</p>
4032
4033 <pre><code>    # OLD, perltidy -wn
4034     # qw line
4035     if ( $pos == 0 ) {
4036         @return = grep( /^$word/,
4037             sort qw(
4038               ! a b d h i m o q r u autobundle clean
4039               make test install force reload look
4040         ) ); #&lt;-- outdented more than &#39;sort&#39;
4041     }
4042
4043     # Here is the same with a list instead of a qw; note how the
4044     # closing sort paren does not outdent more than the &#39;sort&#39; line.
4045     # This is the desired result for qw.
4046     # perltidy -wn
4047     if ( $pos == 0 ) {
4048         @return = grep( /^$word/,
4049             sort (
4050
4051                 &#39;!&#39;,          &#39;a&#39;, &#39;b&#39;, &#39;d&#39;, &#39;h&#39;, &#39;i&#39;, &#39;m&#39;, &#39;o&#39;, &#39;q&#39;, &#39;r&#39;, &#39;u&#39;,
4052                 &#39;autobundle&#39;, &#39;clean&#39;,
4053                 &#39;make&#39;,       &#39;test&#39;, &#39;install&#39;, &#39;force&#39;, &#39;reload&#39;, &#39;look&#39;
4054             ) );  #&lt;-- not outdented more than &#39;sort&#39;
4055     }
4056
4057     # NEW (perltidy -wn)
4058     if ( $pos == 0 ) {
4059         @return = grep( /^$word/,
4060             sort qw(
4061               ! a b d h i m o q r u autobundle clean
4062               make test install force reload look
4063             ) ); #&lt;-- not outdented more than sort
4064     }</code></pre>
4065
4066 <p>Here is another example # OLD: $_-&gt;meta-&gt;make_immutable( inline_constructor =&gt; 0, constructor_name =&gt; &quot;_new&quot;, inline_accessors =&gt; 0, ) for qw( Class::XYZ::Package Class::XYZ::Module Class::XYZ::Class</p>
4067
4068 <pre><code>        Class::XYZ::Overload
4069     );  #&lt;-- outdented more than the line with &#39;for qw(&#39;
4070
4071     # NEW:
4072     $_-&gt;meta-&gt;make_immutable(
4073         inline_constructor =&gt; 0,
4074         constructor_name   =&gt; &quot;_new&quot;,
4075         inline_accessors   =&gt; 0,
4076       )
4077       for qw(
4078       Class::XYZ::Package
4079       Class::XYZ::Module
4080       Class::XYZ::Class
4081
4082       Class::XYZ::Overload
4083       ); #&lt;-- outdented same as the line with &#39;for qw(&#39;</code></pre>
4084
4085 <p>26 Dec 2020, cdbf0e4.</p>
4086
4087 </dd>
4088 <dt id="improve-list-marking-method"><b>improve list marking method</b></dt>
4089 <dd>
4090
4091 <p>In the process of making vertical alignments, lines which are simple lists of items are treated different from other lines. The old method for finding and marking these lines had a few problems which are corrected with this update. The main problem was that the old method ran into trouble when there were side comments. For example, the old method was not marking the following list and as a result the two columns of values were not aligned:</p>
4092
4093 <pre><code>    # OLD
4094     return (
4095         $startpos, $ldelpos - $startpos,         # PREFIX
4096         $ldelpos,  1,                            # OPENING BRACKET
4097         $ldelpos + 1, $endpos - $ldelpos - 2,    # CONTENTS
4098         $endpos - 1, 1,                          # CLOSING BRACKET
4099         $endpos, length($$textref) - $endpos,    # REMAINDER
4100     );
4101
4102     # NEW
4103     return (
4104         $startpos,    $ldelpos - $startpos,           # PREFIX
4105         $ldelpos,     1,                              # OPENING BRACKET
4106         $ldelpos + 1, $endpos - $ldelpos - 2,         # CONTENTS
4107         $endpos - 1,  1,                              # CLOSING BRACKET
4108         $endpos,      length($$textref) - $endpos,    # REMAINDER
4109     );</code></pre>
4110
4111 <p>Another problem was that occasionally unwanted alignments were made between lines which were not really lists because the lines were incorrectly marked. For example (note padding after first comma)</p>
4112
4113 <pre><code>    # OLD: (undesirable alignment)
4114     my ( $isig2, $chisq ) = ( 1 / ( $sig * $sig ), 0 );
4115     my ( $ym,    $al, $cov, $bet, $olda, $ochisq, $di, $pivt, $info ) =
4116       map { null } ( 0 .. 8 );
4117
4118     # NEW: (no alignment)
4119     my ( $isig2, $chisq ) = ( 1 / ( $sig * $sig ), 0 );
4120     my ( $ym, $al, $cov, $bet, $olda, $ochisq, $di, $pivt, $info ) =
4121       map { null } ( 0 .. 8 );</code></pre>
4122
4123 <p>This update was made 22 Dec 2020, 36d4c35.</p>
4124
4125 </dd>
4126 <dt id="Fix-git-51-closing-quote-pattern-delimiters-not-following--cti-flag-settings"><b>Fix git #51, closing quote pattern delimiters not following -cti flag settings</b></dt>
4127 <dd>
4128
4129 <p>Closing pattern delimiter tokens of qw quotes were not following the -cti flag settings for containers in all cases, as would be expected, in particular when followed by a comma. For example, the closing qw paren below was indented with continuation indentation but would not have that extra indentation if it followed the default -cpi setting for a paren:</p>
4130
4131 <pre><code>    # OLD:
4132     @EXPORT = (
4133         qw(
4134           i Re Im rho theta arg
4135           sqrt log ln
4136           log10 logn cbrt root
4137           cplx cplxe
4138           ),
4139         @trig
4140     );
4141
4142     # NEW
4143     @EXPORT = (
4144         qw(
4145             i Re Im rho theta arg
4146             sqrt log ln
4147             log10 logn cbrt root
4148             cplx cplxe
4149         ),
4150         @trig
4151     );</code></pre>
4152
4153 <p>This update makes closing qw quote terminators follow the settings for their corresponding container tokens as closely as possible. For a closing &#39;&gt;&#39; the setting for a closing paren will now be followed. Other closing qw terminators will remain indented, to minimize changes to existing formatting. For example (&#39;&gt;&#39; is outdented):</p>
4154
4155 <pre><code>    @EXPORT = (
4156         qw&lt;
4157           i Re Im rho theta arg
4158           sqrt log ln
4159           log10 logn cbrt root
4160           cplx cplxe
4161         &gt;,
4162         @trig
4163     );</code></pre>
4164
4165 <p>but (&#39;;&#39; remains indented):</p>
4166
4167 <pre><code>    @EXPORT = (
4168         qw;
4169           i Re Im rho theta arg
4170           sqrt log ln
4171           log10 logn cbrt root
4172           cplx cplxe
4173           ;,
4174         @trig
4175     );</code></pre>
4176
4177 <p>This update was added 18 Dec 2020 and modified 24 Dec 2020, 538688f.</p>
4178
4179 </dd>
4180 <dt id="Update-manual-pages-regarding-issue-git-50"><b>Update manual pages regarding issue git #50</b></dt>
4181 <dd>
4182
4183 <p>Additional wording was added to the man pages regarding situations in which perltidy does not change whitespace. This update was added 17 Dec 2020.</p>
4184
4185 </dd>
4186 <dt id="Rewrote-sub-check_match"><b>Rewrote sub check_match</b></dt>
4187 <dd>
4188
4189 <p>Moved inner part of sub check_match into sub match_line_pair in order to make info available earlier. This gave some minor alignment improvements. This was done 16 Dec 2020, 7ba4f3b.</p>
4190
4191 <pre><code>    # OLD:
4192     @tests = (
4193         @common,     &#39;$_&#39;,
4194         &#39;&quot;\$_&quot;&#39;,     &#39;@_&#39;,
4195         &#39;&quot;\@_&quot;&#39;,     &#39;??N&#39;,
4196         &#39;&quot;??N&quot;&#39;,     chr 256,
4197         &#39;&quot;\x{100}&quot;&#39;, chr 65536,
4198         &#39;&quot;\x{10000}&quot;&#39;, ord &#39;N&#39; == 78 ? ( chr 11, &#39;&quot;\013&quot;&#39; ) : ()
4199     );
4200
4201     # NEW:
4202     @tests = (
4203         @common,       &#39;$_&#39;,
4204         &#39;&quot;\$_&quot;&#39;,       &#39;@_&#39;,
4205         &#39;&quot;\@_&quot;&#39;,       &#39;??N&#39;,
4206         &#39;&quot;??N&quot;&#39;,       chr 256,
4207         &#39;&quot;\x{100}&quot;&#39;,   chr 65536,
4208         &#39;&quot;\x{10000}&quot;&#39;, ord &#39;N&#39; == 78 ? ( chr 11, &#39;&quot;\013&quot;&#39; ) : ()
4209     );</code></pre>
4210
4211 </dd>
4212 <dt id="Improved-vertical-alignments-by-avoiding-pruning-step"><b>Improved vertical alignments by avoiding pruning step</b></dt>
4213 <dd>
4214
4215 <p>There is a step in vertical alignment where the alignments are formed into a tree with different levels, and some deeper levels are pruned to preserve lower level alignments. This usually works well, but some deeper alignments will be lost, which is what was happening in the example below. It turns out that if the tree pruning is skipped when alignment depths increase monotonically across lines, as in the example, then better overall alignment is achieved by the subsequent &#39;sweep&#39; pass.</p>
4216
4217 <pre><code>    # OLD
4218     my $cmd = shift @ARGV;
4219     if    ( $cmd eq &quot;new&quot; )         { $force_new = 1; }
4220     elsif ( $cmd eq &quot;interactive&quot; ) { $interactive = 1; $batch       = 0; }
4221     elsif ( $cmd eq &quot;batch&quot; )       { $batch       = 1; $interactive = 0; }
4222     elsif ( $cmd eq &quot;use_old&quot; )     { $use_old = 1; }
4223     elsif ( $cmd eq &quot;show&quot; )        { $show    = 1; last; }
4224     elsif ( $cmd eq &quot;showall&quot; )     { $showall = 1; last; }
4225     elsif ( $cmd eq &quot;show_all&quot; )    { $showall = 1; last; }
4226     elsif ( $cmd eq &quot;remove&quot; )      { $remove  = 1; last; }
4227     elsif ( $cmd eq &quot;help&quot; )        { $help    = 1; last; }
4228
4229     # NEW
4230     my $cmd = shift @ARGV;
4231     if    ( $cmd eq &quot;new&quot; )         { $force_new   = 1; }
4232     elsif ( $cmd eq &quot;interactive&quot; ) { $interactive = 1; $batch       = 0; }
4233     elsif ( $cmd eq &quot;batch&quot; )       { $batch       = 1; $interactive = 0; }
4234     elsif ( $cmd eq &quot;use_old&quot; )     { $use_old     = 1; }
4235     elsif ( $cmd eq &quot;show&quot; )        { $show        = 1; last; }
4236     elsif ( $cmd eq &quot;showall&quot; )     { $showall     = 1; last; }
4237     elsif ( $cmd eq &quot;show_all&quot; )    { $showall     = 1; last; }
4238     elsif ( $cmd eq &quot;remove&quot; )      { $remove      = 1; last; }
4239     elsif ( $cmd eq &quot;help&quot; )        { $help        = 1; last; }</code></pre>
4240
4241 <p>This update was made 14 Dec 2020, 44e0afa.</p>
4242
4243 </dd>
4244 <dt id="Improved-some-marginal-vertical-alignments"><b>Improved some marginal vertical alignments</b></dt>
4245 <dd>
4246
4247 <p>This update fixed a rare situation in which some vertical alignment was missed. The problem had to do with two lines being incorrectly marked as a marginal match. A new routine, &#39;match_line_pairs&#39; was added to set a flag with the information needed to detect and prevent this. This fix was made 13 Dec 2020, 9a8e49b.</p>
4248
4249 <pre><code>    # OLD
4250     $sec = $sec + ( 60 * $min );
4251     $graphcpu[$sec] = $line;
4252     $secmax  = $sec  if ( $sec &gt; $secmax );
4253     $linemax = $line if ( $line &gt; $linemax );
4254
4255     # NEW
4256     $sec            = $sec + ( 60 * $min );
4257     $graphcpu[$sec] = $line;
4258     $secmax         = $sec  if ( $sec &gt; $secmax );
4259     $linemax        = $line if ( $line &gt; $linemax );</code></pre>
4260
4261 </dd>
4262 <dt id="Do-not-align-equals-across-changes-in-continuation-indentation"><b>Do not align equals across changes in continuation indentation</b></dt>
4263 <dd>
4264
4265 <p>A rule was added to prevent vertical alignment of lines with leading &#39;=&#39; across a change in continuation indentation. Sometimes aligning across a change in CI can come out okay, but sometimes it can be very poor. For example:</p>
4266
4267 <pre><code>    # BAD:
4268     $!               = 2, die qq/$0: can&#39;t stat -${arg}&#39;s &quot;$file&quot;./
4269         unless $time = ( stat($file) )[$STAT_MTIME];
4270
4271     # FIXED:
4272     $! = 2, die qq/$0: can&#39;t stat -${arg}&#39;s &quot;$file&quot;./
4273       unless $time = ( stat($file) )[$STAT_MTIME];</code></pre>
4274
4275 <p>The second line is a continuation of the first, and this update prevents this alignment. The above &#39;BAD&#39; formatting was in the previous developmental version of perltidy, not the previous release. This update added 12 Dec 2020, 5b56147.</p>
4276
4277 </dd>
4278 <dt id="Improve-vertical-alignment-in-some-two-line-matches"><b>Improve vertical alignment in some two-line matches</b></dt>
4279 <dd>
4280
4281 <p>When two lines would be perfectly aligned except for the line length limit, previously they would only be aligned if they had a common leading equals. The update removes this restriction and allows as many alignments to be made as possible. The results are generally improved. This update was made 11 Dec 2020, f3c6cd8. Some examples:</p>
4282
4283 <p># In this example the side comments were limiting the matches</p>
4284
4285 <pre><code>    # OLD
4286     shift @data if @data and $data[0] =~ /Contributed\s+Perl/;    # Skip header
4287     pop @data if @data and $data[-1] =~ /^\w/;    # Skip footer, like
4288
4289     # NEW
4290     shift @data if @data and $data[0]  =~ /Contributed\s+Perl/;    # Skip header
4291     pop @data   if @data and $data[-1] =~ /^\w/;    # Skip footer, like</code></pre>
4292
4293 <p># The same is true here.</p>
4294
4295 <pre><code>    # OLD
4296     if ($tvg::o_span) { $tvg::hour_span = $tvg::o_span; }
4297     if ( $tvg::hour_span % 2 &gt; 0 ) { $tvg::hour_span++; }    # Multiple of 2
4298
4299     # NEW
4300     if ($tvg::o_span)              { $tvg::hour_span = $tvg::o_span; }
4301     if ( $tvg::hour_span % 2 &gt; 0 ) { $tvg::hour_span++; }    # Multiple of 2</code></pre>
4302
4303 <p>In the next example, the first comma is now aligned but not the second, because of the line length limit:</p>
4304
4305 <pre><code>    # OLD
4306     is( MyClass-&gt;meta, $mc, &#39;... these metas are still the same thing&#39; );
4307     is( MyClass-&gt;meta-&gt;meta, $mc-&gt;meta, &#39;... these meta-metas are the same thing&#39; );
4308
4309     # NEW
4310     is( MyClass-&gt;meta,       $mc, &#39;... these metas are still the same thing&#39; );
4311     is( MyClass-&gt;meta-&gt;meta, $mc-&gt;meta, &#39;... these meta-metas are the same thing&#39; );</code></pre>
4312
4313 <p>In this last example, the first comma is not aligned, but alignment resumes after the second comma.</p>
4314
4315 <pre><code>    # OLD
4316     is( $obj-&gt;name, $COMPRESS_FILE, &quot;   Name now set to &#39;$COMPRESS_FILE&#39;&quot; );
4317     is( $obj-&gt;prefix, &#39;&#39;, &quot;   Prefix now empty&quot; );
4318
4319     # NEW
4320     is( $obj-&gt;name, $COMPRESS_FILE, &quot;   Name now set to &#39;$COMPRESS_FILE&#39;&quot; );
4321     is( $obj-&gt;prefix, &#39;&#39;,           &quot;   Prefix now empty&quot; );</code></pre>
4322
4323 </dd>
4324 <dt id="Improve-vertical-alignment-in-some-marginal-matches"><b>Improve vertical alignment in some marginal matches</b></dt>
4325 <dd>
4326
4327 <p>In perltidy a &#39;marginal match&#39; occurs for example when two lines share some alignment tokens but are somewhat different. When this happens some limits are placed on the size of the padding spaces that can be introduced. In this update the amount of allowed padding is significantly increased for certain &#39;good&#39; alignment tokens. Results of extensive testing were favorable provided that the change is restricted to alignments of &#39;=&#39;, &#39;if&#39; and &#39;unless&#39;. Update made 10 Dec 2020, a585f0b.</p>
4328
4329 <pre><code>    # OLD
4330     my @roles = $self-&gt;role_names;
4331     my $role_names = join &quot;|&quot;, @roles;
4332
4333     # NEW
4334     my @roles      = $self-&gt;role_names;
4335     my $role_names = join &quot;|&quot;, @roles;
4336
4337     # OLD
4338     $sysname .= &#39;del&#39; if $self-&gt;label =~ /deletion/;
4339     $sysname .= &#39;ins&#39; if $self-&gt;label =~ /insertion/;
4340     $sysname .= uc $self-&gt;allele_ori-&gt;seq if $self-&gt;allele_ori-&gt;seq;
4341
4342     # NEW
4343     $sysname .= &#39;del&#39;                     if $self-&gt;label =~ /deletion/;
4344     $sysname .= &#39;ins&#39;                     if $self-&gt;label =~ /insertion/;
4345     $sysname .= uc $self-&gt;allele_ori-&gt;seq if $self-&gt;allele_ori-&gt;seq;</code></pre>
4346
4347 </dd>
4348 <dt id="Improve-vertical-alignment-of-lines-ending-in-fat-comma"><b>Improve vertical alignment of lines ending in fat comma</b></dt>
4349 <dd>
4350
4351 <p>A minor adjustment was made to the rule for aligning lines which end in &#39;=&gt;&#39;. When there are just two lines in an alignment group, the alignment is avoided if the first of the two ends in a &#39;=&gt;&#39;. Previously, alignment was avoided if either ended in a &#39;=&gt;&#39;. The old rule was preventing some good alignments in a later stage of the iteration. In the following example, the last two lines are processed separately because they do not match the comma in &#39;sprintf&#39;. The new rule allows the fat comma alignment to eventually get made later in the iteration. Update made 9 Dec 2020, ca0ddf4.</p>
4352
4353 <pre><code>    # OLD
4354     $template-&gt;param(
4355         classlist =&gt; $classlist,
4356         ...,
4357         suggestion =&gt; $suggestion,
4358         totspent   =&gt; sprintf( &quot;%.2f&quot;, $totspent ),
4359         totcomtd   =&gt; sprintf( &quot;%.2f&quot;, $totcomtd ),
4360         totavail   =&gt; sprintf( &quot;%.2f&quot;, $totavail ),
4361         nobudget =&gt; $#results == -1 ? 1 : 0,
4362         intranetcolorstylesheet =&gt;
4363           C4::Context-&gt;preference(&quot;intranetcolorstylesheet&quot;),
4364         ...
4365     );
4366
4367     # NEW
4368     $template-&gt;param(
4369         classlist =&gt; $classlist,
4370         ...,
4371         suggestion              =&gt; $suggestion,
4372         totspent                =&gt; sprintf( &quot;%.2f&quot;, $totspent ),
4373         totcomtd                =&gt; sprintf( &quot;%.2f&quot;, $totcomtd ),
4374         totavail                =&gt; sprintf( &quot;%.2f&quot;, $totavail ),
4375         nobudget                =&gt; $#results == -1 ? 1 : 0,
4376         intranetcolorstylesheet =&gt;
4377           C4::Context-&gt;preference(&quot;intranetcolorstylesheet&quot;),
4378         ...
4379     );</code></pre>
4380
4381 </dd>
4382 <dt id="Avoid-processing-a-file-more-than-once"><b>Avoid processing a file more than once</b></dt>
4383 <dd>
4384
4385 <p>In the unlikely event that a user enters a filename more than once on the command line to perltidy, as for &#39;file1.pl&#39; here</p>
4386
4387 <pre><code>  perltidy file1.pl file1.pl </code></pre>
4388
4389 <p>then that file will be processed more than once. This looks harmless, but if the user was also using the -b (backup) parameter, then the original backup would be overwritten, which is not good. To avoid this, a filter has been placed on the list of files to remove duplicates. 9 Dec 2020, 646a542.</p>
4390
4391 </dd>
4392 <dt id="Fix-for-issue-git-49-exit-status-not-correctly-set"><b>Fix for issue git #49, exit status not correctly set</b></dt>
4393 <dd>
4394
4395 <p>The exit status flag was not being set for the -w option if the -se or if the -q flag were set. Issue git #44 was similar but a special case of the problem. The problem was fixed 8 Dec 2020, cb6028f.</p>
4396
4397 </dd>
4398 </dl>
4399
4400 <h1 id="Issues-fixed-after-release-20201202">Issues fixed after release 20201202</h1>
4401
4402 <dl>
4403
4404 <dt id="Fix-for-issue-git-47"><b>Fix for issue git #47</b></dt>
4405 <dd>
4406
4407 <p>This issue has to do with the --weld-nested-containers option in the specific case of formatting a function which returns a list of anonymous subs. For example</p>
4408
4409 <pre><code>    $promises[$i]-&gt;then(
4410         sub { $all-&gt;resolve(@_); () },
4411         sub {
4412             $results-&gt;[$i] = [@_];
4413             $all-&gt;reject(@$results) if --$remaining &lt;= 0;
4414             return ();
4415         }
4416     );</code></pre>
4417
4418 <p>A bug introduced in v20201202 caused an incorrect welding to occur when the -wn flag was set</p>
4419
4420 <pre><code>    $promises[$i]-&gt;then( sub { $all-&gt;resolve(@_); () },
4421         sub {
4422         $results-&gt;[$i] = [@_];
4423         $all-&gt;reject(@$results) if --$remaining &lt;= 0;
4424         return ();
4425         } );</code></pre>
4426
4427 <p>This bug has been fixed, and code which has been incorrectly formatted will be correctly formatted with the next release. The bug was a result of a new coding introduced in v20201202 for fixing some issues with parsing sub signatures. Previously they were sometimes parsed the same as prototypes and sometimes as lists, now they are always parsed as lists. Fixed 6 Dec 2020, 6fd0c4f.</p>
4428
4429 </dd>
4430 </dl>
4431
4432 <h1 id="Issues-fixed-after-release-20201001">Issues fixed after release 20201001</h1>
4433
4434 <dl>
4435
4436 <dt id="removed-excess-spaces-in-a-package-declaration"><b>removed excess spaces in a package declaration</b></dt>
4437 <dd>
4438
4439 <p>Testing revealed that for a line such as</p>
4440
4441 <pre><code>   package        Bob::Dog;</code></pre>
4442
4443 <p>which has extra spaces or even tabs after the keyword &#39;package&#39;, the extra spaces or tabs were not being removed. This was fixed 28 Nov 2020, 008443d. The line now formats to</p>
4444
4445 <pre><code>    package Bob::Dog;</code></pre>
4446
4447 </dd>
4448 <dt id="do-not-automatically-delete-closing-side-comments-with---indent-only"><b>do not automatically delete closing side comments with --indent-only</b></dt>
4449 <dd>
4450
4451 <p>For the parameter combination --indent-only and --closing-side-comments, old closing side comments were getting deleted but new closing side comments were not made. A fix was made to prevent this deletion. This fix was made 27 Nov 2020, 957e0ca.</p>
4452
4453 </dd>
4454 <dt id="fix-to-stop-at-1-iteration-when-using---indent-only"><b>fix to stop at 1 iteration when using --indent-only</b></dt>
4455 <dd>
4456
4457 <p>Previously, for the combination --indent-only and -conv, two iterations would be done. Only one iteration is necessary in this case. Fix made 23 Nov 2020, ae493d8.</p>
4458
4459 </dd>
4460 <dt id="fix-for-formatting-signed-numbers-with-spaces"><b>fix for formatting signed numbers with spaces</b></dt>
4461 <dd>
4462
4463 <p>In developing an improved convergence test, an issue slowing convergence was found related to signed numbers as in the following line,</p>
4464
4465 <pre><code>    @london = (deg2rad(-  0.5), deg2rad(90 - 51.3));</code></pre>
4466
4467 <p>The leading &#39;-&#39; here is separated from the following number &#39;0.5&#39;. This is handled by tokenizing the minus as type &#39;m&#39; and the number as type &#39;n&#39;. The whitespace between them is removed in formatting, and so the space is gone in the output. But a little problem is that the default rule for placing spaces within the parens is based on the token count, after the first formatting the result is</p>
4468
4469 <pre><code>    @london = ( deg2rad( -0.5 ), deg2rad( 90 - 51.3 ) );</code></pre>
4470
4471 <p>The next time it is formatted, the &#39;-0.5&#39; counts as one token, resulting in</p>
4472
4473 <pre><code>    @london = ( deg2rad(-0.5), deg2rad( 90 - 51.3 ) );</code></pre>
4474
4475 <p>Notice that the space within the parens around the &#39;-0.5&#39; is gone. An update was made to fix this, so that the final state is reached in one step. This fix was made 23 Nov 2020, f477c8b.</p>
4476
4477 </dd>
4478 <dt id="fix-to-prevent-conversion-of-a-block-comment-to-hanging-side-comment"><b>fix to prevent conversion of a block comment to hanging side comment</b></dt>
4479 <dd>
4480
4481 <p>A rare situation was identified during testing in which a block comment could be converted to be a hanging side comment. For example:</p>
4482
4483 <pre><code>    sub macro_get_names {    #
4484     #
4485     # %name = macro_get_names();  (key=macrohandle, value=macroname)
4486     #
4487         local (%name) = ();
4488         ...
4489     }</code></pre>
4490
4491 <p>For the following specific contitions the block comment in line 2 could be converted into a hanging side comment, which is undesirable:</p>
4492
4493 <pre><code>   1. The line contains nothing except for a &#39;#&#39; with no leading space
4494    2. It follows a line with side comment
4495    3. It has indentation level &gt; 0</code></pre>
4496
4497 <p>An update was made to prevent this from happening. There are two cases, depending on the value of --maximum-consecutive-blank-lines, or -mbl. If this value is positive (the default) then a blank line is inserted above the block comment to prevent it from becoming a hanging side comment. If this -mbl is zero, then the comment is converted to be a static block comment which again prevents it from becoming a hanging side comment. This fix was made 23 Nov 2020, 2eb3de1.</p>
4498
4499 </dd>
4500 <dt id="improved-convergence-test"><b>improved convergence test</b></dt>
4501 <dd>
4502
4503 <p>A better test for convergence has been added. When iterations are requested, the new test will stop after the first pass if no changes in line break locations are made. Previously, at least two passes were required to verify convergnece unless the output stream had the same checksum as the input stream. Extensive testing has been made to verify the correctness of the new test. This update was made 23 Nov 2020, 29efb63.</p>
4504
4505 </dd>
4506 <dt id="fixed-problem-with-vertical-alignments-involving-if-statements"><b>fixed problem with vertical alignments involving &#39;if&#39; statements</b></dt>
4507 <dd>
4508
4509 <p>An update was made to break vertical alignment when a new sequence of if-like statements or ternary statements is encountered. This situation was causing a loss of alignment in some cases. For example</p>
4510
4511 <pre><code>  OLD:
4512     $m1 = 0;
4513     if ( $value =~ /\bset\b/i )      { $m0 = 1; }
4514     if ( $value =~ /\barithmetic/i ) { $m1 = 1; }
4515     if    ( $m0 &amp;&amp; !$m1 ) { $CONFIG[1] = 0; }
4516     elsif ( !$m0 &amp;&amp; $m1 ) { $CONFIG[1] = 1; }
4517     else                  { $ok        = 0; last; }
4518
4519  NEW:
4520     $m1 = 0;
4521     if    ( $value =~ /\bset\b/i )      { $m0        = 1; }
4522     if    ( $value =~ /\barithmetic/i ) { $m1        = 1; }
4523     if    ( $m0 &amp;&amp; !$m1 )               { $CONFIG[1] = 0; }
4524     elsif ( !$m0 &amp;&amp; $m1 )               { $CONFIG[1] = 1; }
4525     else                                { $ok        = 0; last; }</code></pre>
4526
4527 <p>This update was made 15 Nov 2020, 2b7784d.</p>
4528
4529 </dd>
4530 <dt id="added-option--wnxl-s-to-give-control-of-welding-by-the--wn-parameter"><b>added option -wnxl=s to give control of welding by the -wn parameter</b></dt>
4531 <dd>
4532
4533 <p>The parameter string can restrict the types of containers which are welded. This was added 11 Nov 2020 in &#39;added -wnxl=s for control of -wn&#39;, 2e642d2.</p>
4534
4535 </dd>
4536 <dt id="merged-pull-request-git-46"><b>merged pull request git #46</b></dt>
4537 <dd>
4538
4539 <p>The man page gave the incorrect string for -fse. This was fixed 11 Nov 2020 in 1f9869e.</p>
4540
4541 </dd>
4542 <dt id="recognize-overloaded-RPerl-operators-to-avoid-error-messages"><b>recognize overloaded RPerl operators to avoid error messages</b></dt>
4543 <dd>
4544
4545 <p>RPerl uses some bareword operators which caused error messages. An update was made to avoid this problem in files containing &#39;use RPerl&#39;. This update was made 6 Nov 2020, f8bd088.</p>
4546
4547 </dd>
4548 <dt id="fix-issue-git-45--wn-and--vtc-n-now-work-together"><b>fix issue git #45, -wn and -vtc=n now work together</b></dt>
4549 <dd>
4550
4551 <p>When -wn was set, the -vtc=n flag was being ignored. This was a simple fix made 5 Nov 2020 in &#39;fix issue git #45, -wn and -vtc=n now work together&#39;, 1fbc381.</p>
4552
4553 </dd>
4554 <dt id="implement-request-RT-133649-added-parameters--kbb-s-and--kba-s"><b>implement request RT #133649, added parameters -kbb=s and -kba=s</b></dt>
4555 <dd>
4556
4557 <p>These parameters request that old breakpoints be kept before or after selected token types. For example, -kbb=&#39;=&gt;&#39; means that newlines before fat commas should be kept. This was added 4 Nov 2020.</p>
4558
4559 </dd>
4560 <dt id="added-parameters--maxue-n-and-maxle-n"><b>added parameters -maxue=n and maxle=n</b></dt>
4561 <dd>
4562
4563 <p>These parameters had tentatively been hardwired in the tokenizer. Now the user can control them or turn the checks off altogether.</p>
4564
4565 </dd>
4566 <dt id="Fix-problem-parsing"><b>Fix problem parsing &#39;$$*&#39;</b></dt>
4567 <dd>
4568
4569 <p>In random testing, an error was encountered parsing the following line</p>
4570
4571 <pre><code>  $self-&gt;{&quot;mod_id&quot;}=($$*1001)%(10**(rand()*6));
4572                        ---^
4573   found Number where operator expected (previous token underlined)</code></pre>
4574
4575 <p>The line parsed correctly with a space between the &#39;$$&#39; and the &#39;*&#39;. The problem had to do with an error in some newer code for postfix dereferencing, and this was fixed on 2 Nov 2020, &#39;fix problem scanning &#39;$$&#39;; revise call to operator_expected&#39;, 49d993b.</p>
4576
4577 </dd>
4578 <dt id="Update-for-git-44-fix-exit-status-for-assert-tidy-untidy"><b>Update for git #44, fix exit status for assert-tidy/untidy</b></dt>
4579 <dd>
4580
4581 <p>The exit status was always 0 for --assert-tidy if the user had turned off error messages with -quiet. This was fixed by gluesys/master in &#39;fix exit status for assert-tidy/untidy options&#39;, 625d250.</p>
4582
4583 </dd>
4584 <dt id="Fixed-problem-parsing-extruded-signature"><b>Fixed problem parsing extruded signature</b></dt>
4585 <dd>
4586
4587 <p>A parsing error was encountered in a test parsing the following extruded signature:</p>
4588
4589 <pre><code>  sub foo2
4590   (
4591   $
4592   first
4593   ,
4594   $
4595   ,
4596   $
4597   third
4598   )
4599   {
4600   return
4601   &quot;first=$first, third=$third&quot;
4602   ;
4603   }</code></pre>
4604
4605 <p>The second &#39;$&#39; combined with the &#39;,&#39; on the next line to form a punctuation variable. This was fixed 20 Oct 2020 in &#39;fixed problem parsing extruded signature&#39;, 9b454f6.</p>
4606
4607 <p>The file parses correctly now, with formatted output</p>
4608
4609 <pre><code>  sub foo2 ( $first, $, $third ) {
4610       return &quot;first=$first, third=$third&quot;;
4611   }</code></pre>
4612
4613 </dd>
4614 <dt id="Fixed-several-uses-of-undefined-variables-found-in-testing"><b>Fixed several uses of undefined variables found in testing</b></dt>
4615 <dd>
4616
4617 <p>Several instances of incorrect array indexing were found in testing and fixed. These each involved incorrectly indexing with index -1. They were found by placing undefs at the end of arrays. None of these was causing incorrect formatting. They were fixed 26 Oct 2020 in &#39;fixed several instances of incorrect array indexing&#39;, c60f694.</p>
4618
4619 </dd>
4620 <dt id="Prevent-syntax-error-by-breaking-dashed-package-names"><b>Prevent syntax error by breaking dashed package names</b></dt>
4621 <dd>
4622
4623 <p>In stress testing perltidy with the -extrude option, the following test snippet</p>
4624
4625 <pre><code>  use perl6-alpha;</code></pre>
4626
4627 <p>was broken into sepate lines</p>
4628
4629 <pre><code>  use
4630   perl6
4631   -
4632   alpha
4633   ;</code></pre>
4634
4635 <p>A rule was added to prevent breaking around a dash separating two barewords. Rerunning gives</p>
4636
4637 <pre><code>  use
4638   perl6-alpha
4639   ;</code></pre>
4640
4641 <p>This was fixed 26 Oct 2020 in &#39;prevent breaking package names with trailing dashes&#39;, 9234be4.</p>
4642
4643 </dd>
4644 <dt id="Prevent-syntax-error-by-breaking-dashed-barewords"><b>Prevent syntax error by breaking dashed barewords</b></dt>
4645 <dd>
4646
4647 <p>In stress testing perltidy with the -extrude option, using the following test snippet</p>
4648
4649 <pre><code>  my %var;
4650   {
4651       $var{-y}  = 1;
4652       $var{-q}  = 1;
4653       $var{-qq} = 1;
4654       $var{-m}  = 1;
4655       $var{y}   = 1;
4656       $var{q}   = 1;
4657       $var{qq}  = 1;
4658       $var{m}   = 1;
4659   }</code></pre>
4660
4661 <p>a syntax error was created when newlines were placed before or after the dashes. It is necessary to always keep a dash on the same line with its surrounding tokens. A rule was added to do this. The new &#39;extruded&#39; result for the above snippet is:</p>
4662
4663 <pre><code>  my%var
4664   ;
4665   {
4666   $var{-y}
4667   =
4668   1
4669   ;
4670   $var{-q}
4671   =
4672   1
4673   ;
4674   $var{-qq}
4675   =
4676   1
4677   ;
4678   $var{-m}
4679   =
4680   1
4681   ;
4682   $var{y}
4683   =
4684   1
4685   ;
4686   $var{q}
4687   =
4688   1
4689   ;
4690   $var{qq}
4691   =
4692   1
4693   ;
4694   $var{m}
4695   =
4696   1
4697   ;
4698   }</code></pre>
4699
4700 <p>This update was added 26 Oct 2020, &#39;prevent syntax error by breaking dashed barewords&#39;, e121cae.</p>
4701
4702 </dd>
4703 <dt id="more-types-of-severe-errors-will-prevent-formatting"><b>more types of severe errors will prevent formatting</b></dt>
4704 <dd>
4705
4706 <p>Files for which &#39;severe errors&#39; are found have always been output verbatim rather than being formatted. The definition of &#39;severe error&#39; has been expanded to include a final indentation level error greater than 1, more than 2 brace errors, and more than 3 &quot;unexpected token type&quot; parsing errors. The goal is to avoid formatting a non-perl script or a perl script with severe errors. So for example the following snippet has a level error of 2</p>
4707
4708 <pre><code>  {{{{
4709   }}</code></pre>
4710
4711 <p>was previously output with default parameters as</p>
4712
4713 <pre><code>  {
4714       {
4715           {
4716               {}
4717           }</code></pre>
4718
4719 <p>along with an error message. But now it is just output verbatim as</p>
4720
4721 <pre><code>  {{{{
4722   }}</code></pre>
4723
4724 <p>along with an error message. This update was added 25 Oct 2020, &#39;avoid formatting files with more types of severe errors&#39;, 2a86f51.</p>
4725
4726 </dd>
4727 <dt id="added-state-as-keyword"><b>added &#39;state&#39; as keyword</b></dt>
4728 <dd>
4729
4730 <p>A statement such as the following was generating an error message at the colon:</p>
4731
4732 <pre><code>   state $a : shared;</code></pre>
4733
4734 <p>The problem was that &#39;state&#39; was not in the list of keywords. This has been fixed and the line now parses without error. The &#39;state.t&#39; test file for perl 5.31 now formats without error. This was added 18 Oct 2020 in &quot;add &#39;state&#39; as keyword&quot;, d73e15f.</p>
4735
4736 </dd>
4737 <dt id="sub-signatures-no-longer-parsed-with-prototypes"><b>sub signatures no longer parsed with prototypes</b></dt>
4738 <dd>
4739
4740 <p>Simple signatures (those without commas) were being parsed with code originally written for prototypes. This prevented them from being formatted with the usual formatting rules. This was changed so that all signatures are now formatted with the normal formatting rules. For example:</p>
4741
4742 <pre><code> # Old, input and after formatting:
4743  sub t123 ($list=wantarray) { $list ? &quot;list&quot; : &quot;scalar&quot; }
4744
4745  # New, after formatting
4746  sub t123 ( $list = wantarray ) { $list ? &quot;list&quot; : &quot;scalar&quot; }</code></pre>
4747
4748 <p>Notice that some spaces have been introduced within the signature. Previously the contents of the parens not changed unless the parens contained a list.</p>
4749
4750 <p>This change introduced a problem parsing extended syntax within signatures which has been fixed. In the following snippet, the &#39;:&#39; caused a parsing error which was fixed.</p>
4751
4752 <pre><code>  # perltidy -sal=&#39;method&#39;
4753   method foo4 ( $class : $bar, $bubba ) { $class-&gt;bar($bar) }</code></pre>
4754
4755 <p>The &#39;:&#39; here is given a type of &#39;A&#39;. This may be used to change the spacing around it. For example:</p>
4756
4757 <pre><code>  # perltidy -sal=&#39;method&#39; -nwls=&#39;A&#39;
4758   method foo4 ( $class: $bar, $bubba ) { $class-&gt;bar($bar) }</code></pre>
4759
4760 <p>This update was added 18 Oct 2020, in &#39;format all signatures separately from prototypes&#39;, e6a10f3. The test file &#39;signatures.t&#39; distributed with perl5.31 formats without error now.</p>
4761
4762 </dd>
4763 <dt id="fix-parsing-problem-with"><b>fix parsing problem with $#</b></dt>
4764 <dd>
4765
4766 <p>A problem with parsing variables of the form $# and $#array was found in testing and fixed. For most variables the leading sigil may be separated from the remaining part of the identifier by whitespace. An exception is for a variable beginning with &#39;$#&#39;. If there is any space between the &#39;$&#39; and &#39;#&#39; then the &#39;#&#39; starts a comment. So the following snippet is has valid syntax and is equivalent to $ans=40;</p>
4767
4768 <pre><code>    my $ #
4769     #
4770     ans = 40;</code></pre>
4771
4772 <p>This was being misparsed and was fixed 17 Oct 2020, in &#39;fixed parsing error with spaces in $#&#39; a079cdb.</p>
4773
4774 </dd>
4775 <dt id="fix-missing-line-break-for-hash-of-subs-with-signatures"><b>fix missing line break for hash of subs with signatures</b></dt>
4776 <dd>
4777
4778 <p>During testing the following error was found and fixed. Given the following input snippet:</p>
4779
4780 <pre><code>    get(
4781         on_ready =&gt; sub ($worker) {
4782             $on_ready-&gt;end;
4783             return;
4784         },
4785         on_exit =&gt; sub ( $worker, $status ) { return; },
4786     );</code></pre>
4787
4788 <p>The resulting formatting was</p>
4789
4790 <pre><code>    get(
4791         on_ready =&gt; sub ($worker) {
4792             $on_ready-&gt;end;
4793             return;
4794         }, on_exit =&gt; sub ( $worker, $status ) { return; },
4795     );</code></pre>
4796
4797 <p>Notice that the break after the comma has been lost. The problem was traced to a short-cut taken by the code looking for one-line blocks. The unique circumstances in which this occurred involved a hash of anonymous subs, one with a signature with multiple parameters and short enough to be a one-line block, as in the last sub definition line. This was fixed 17 Oct 2020 in &#39;fix missing line break for hash of subs with signatures&#39;, 51428db.</p>
4798
4799 </dd>
4800 <dt id="fix-issues-with-prototype-and-signature-parsing"><b>fix issues with prototype and signature parsing</b></dt>
4801 <dd>
4802
4803 <p>Problems with parsing prototypes and signatures were found during testing and fixed 17 Oct 2020 in &#39;fixed problem parsing multi-line signatures with comments&#39;, 017fd07. For example the following snippet was mis-parsed because of the hash mark.</p>
4804
4805 <pre><code>    sub test ( # comment )))
4806         $x, $x) { $x+$y }</code></pre>
4807
4808 <p>Complex signature expressions such as the following are now parsed without error:</p>
4809
4810 <pre><code>    sub t086
4811         ( #foo)))
4812         $ #foo)))
4813         a #foo)))
4814         ) #foo)))
4815         { $a.$b }</code></pre>
4816
4817 </dd>
4818 <dt id="improve-guess-for-pattern-or-division"><b>improve guess for pattern or division</b></dt>
4819 <dd>
4820
4821 <p>The following line caused a tokenization error in which the two slashes were parsed as a pattern.</p>
4822
4823 <pre><code>   my $masksize = ceil( Opcode::opcodes / 8 );    # /</code></pre>
4824
4825 <p>This problem was discovered in random testing. When a slash follows a bareword whose prototype is not known to perltidy, it has to guess whether the slash starts a pattern or is a division. The guessing logic was rewritten and improved 14 Oct 2020 in &#39;rewrote logic to guess if divide or pattern&#39;, afebe2f.</p>
4826
4827 </dd>
4828 <dt id="fix--bos-to-keep-isolated-semicolon-breaks-after-block-braces"><b>fix -bos to keep isolated semicolon breaks after block braces</b></dt>
4829 <dd>
4830
4831 <p>The flag <b>-bos</b>, or <b>--break-at-old-semicolon-breakpoints</b>, keeps breaks at old isolated semicolons. For example</p>
4832
4833 <pre><code>    $z = sqrt($x**2 + $y**2)
4834       ;</code></pre>
4835
4836 <p>In testing it was found not to be doing this after braces which require semicolons, such as &#39;do&#39; and anonymous subs. This was fixed 12 Oct 2020 in &#39;fix -bos to work with semicolons after braces&#39;, 03ee7fc. For example</p>
4837
4838 <pre><code>    my $dist = sub {
4839         $z = sqrt( $x**2 + $y**2 )
4840           ;
4841       }
4842       ;</code></pre>
4843
4844 </dd>
4845 <dt id="keep-break-after-use-overload"><b>keep break after &#39;use overload&#39;</b></dt>
4846 <dd>
4847
4848 <p>If a line break occurs after <b>use overload</b> then it will now be kept. Previously it was dropped. For example, this would be kept intact:</p>
4849
4850 <pre><code>                use overload
4851                     &#39;+&#39; =&gt; sub {
4852                         print length $_[2], &quot;\n&quot;;
4853                         my ( $x, $y ) = _order(@_);
4854                         Number::Roman-&gt;new( int $x + $y );
4855                     },
4856                     &#39;-&#39; =&gt; sub {
4857                         my ( $x, $y ) = _order(@_);
4858                         Number::Roman-&gt;new( int $x - $y );
4859                     },
4860                     ...</code></pre>
4861
4862 <p>This keeps the list from shifting to the right and can avoid problems in formatting the list with certain styles, including with the -xci flag. Fixed 12 Oct 2020 in &#39;keep break after use overload statement&#39;, 8485afa.</p>
4863
4864 </dd>
4865 <dt id="added-flag--xci-to-improve-formatting-when--ci-and--i-are-equal-issue-git-28"><b>added flag -xci to improve formatting when -ci and -i are equal, issue git #28</b></dt>
4866 <dd>
4867
4868 <p>This flag causes continuation indentation to &quot;extend&quot; deeper into structures. If you use <b>-ci=n</b> and <b>-i=n</b> with the same value of <b>n</b> you will probably want to set this flag. Since this is a fairly new flag, the default is <b>-nxci</b> to avoid disturbing existing formatting.</p>
4869
4870 </dd>
4871 <dt id="terminal-braces-not-indenting-correctly-with--bli-formatting-issue-git-40"><b>terminal braces not indenting correctly with -bli formatting, issue git #40</b></dt>
4872 <dd>
4873
4874 <p>This problem is illustrated with the following snippet when run with -bli -blil=&#39;*&#39;</p>
4875
4876 <pre><code>    #-bli -bli list=&#39;*&#39;
4877     try
4878       {
4879         die;
4880       }
4881     catch
4882       {
4883         die;
4884       };    # &lt;-- this was not indenting</code></pre>
4885
4886 <p>This was due to conflicting rules and was fixed 1 Oct 2020 in commit &#39;fix issue git #40, incorrect closing brace indentation with -bli&#39;, a5aefe9.</p>
4887
4888 <p>At the same time, it was noted that block types sort/map/grep and eval were not following -bli formatting when -blil=&#39;*&#39; and this was fixed. For example, with corrected formatting, we would have</p>
4889
4890 <pre><code>  # perltidy -bli -blil=&#39;*&#39;
4891     eval
4892       {
4893         my $app = App::perlbrew-&gt;new( &quot;install-patchperl&quot;, &quot;-q&quot; );
4894         $app-&gt;run();
4895       }
4896       or do
4897       {
4898         $error          = $@;
4899         $produced_error = 1;
4900       };</code></pre>
4901
4902 </dd>
4903 </dl>
4904
4905 <h1 id="Issues-fixed-after-release-20200907">Issues fixed after release 20200907</h1>
4906
4907 <p>This is a detailed log of changes since the release 20200907. All bugs were found with the help of automated random testing.</p>
4908
4909 <dl>
4910
4911 <dt id="Keep-any-space-between-a-bareword-and-quote"><b>Keep any space between a bareword and quote</b></dt>
4912 <dd>
4913
4914 <p>In random testing, the -mangle option introduced a syntax error by deleting the space between barewords and quotes (test file &#39;MxScreen&#39;), such as:</p>
4915
4916 <pre><code>  oops&quot;Your login, $Bad_Login, is not valid&quot;;</code></pre>
4917
4918 <p>Sub &#39;is_essential_whitespace&#39; was updated to prevent this on 27 Sep 2020, in &#39;keep any space between a bareword and quote&#39;, f32553c.</p>
4919
4920 </dd>
4921 <dt id="Fixed-some-incorrect-indentation-disagreements-reported-in-LOG-file"><b>Fixed some incorrect indentation disagreements reported in LOG file</b></dt>
4922 <dd>
4923
4924 <p>The .LOG file reports any disagreements between the indentation of the input and output files. This can help locate brace errors. These were incorrect when some of the options were used, including --whitespace-cycle, -bbhb, -nib. This was corrected 24 Sep 2020, &#39;fixed incorrect log entry for indentation disagreement&#39;, 3d40545. At the same time, locations of closing brace indentation disagreements are now tracked and reported in the .ERR file when there is a brace error. This can help localize the error if the file was previously formatted by perltidy.</p>
4925
4926 </dd>
4927 <dt id="If-an-cut-starts-a-POD-section-within-code-give-a-warning"><b>If an =cut starts a POD section within code, give a warning</b></dt>
4928 <dd>
4929
4930 <p>Previously only a complaint was given, which went into the log file and was not normally seen. Perl silently accepts this but it can cause significant problems with pod utilities, so a clear warning is better. This situation arose in testing on random files in combination with a -dp flag and it took some time to understand the results because of the lack of a warning.</p>
4931
4932 </dd>
4933 <dt id="Switched-from-using-an-eval-block-to-the--can-function-for-sub-finish_formatting"><b>Switched from using an eval block to the -</b>can() function for sub finish_formatting&gt;</dt>
4934 <dd>
4935
4936 <p>This is not a bug, but is cleaner coding and insures that error messages get reported. This change was made 20 Sep 2020, &#39;switch from eval { } to -&gt;can(&#39;finish_formatting&#39;)&#39;, 28f2a4f.</p>
4937
4938 </dd>
4939 <dt id="fixed-uninitialized-value-reference"><b>fixed uninitialized value reference</b></dt>
4940 <dd>
4941
4942 <p>The following message was generated during automated testing</p>
4943
4944 <pre><code> Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 12079.
4945  Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 12089.
4946  Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 12097.</code></pre>
4947
4948 <p>The problem could be simplified to running perltidy -wn on this snippet:</p>
4949
4950 <pre><code>     __PACKAGE__-&gt;load_components( qw(
4951 &gt;         Core
4952 &gt;
4953 &gt;     ) );</code></pre>
4954
4955 <p>This was fixed 20 Sep 2020 in &#39;fixed_uninitialized_value&#39;, 8d6c4ed.</p>
4956
4957 </dd>
4958 <dt id="fix-incorrect-parsing-of-certain-deprecated-empty-here-docs"><b>fix incorrect parsing of certain deprecated empty here-docs </b></dt>
4959 <dd>
4960
4961 <p>The following snippet was being incorrectly parsed:</p>
4962
4963 <pre><code> print &lt;&lt;
4964  # Hello World 13!
4965
4966    ;
4967  print &quot;DONE\n&quot;;</code></pre>
4968
4969 <p>This is a deprecated here-doc without a specified target but currently still a valid program. It would have been correctly parsed if the semicolon followed the &#39;&lt;&lt;&#39; operator rather than the here-doc.</p>
4970
4971 <p>This was found in random testing and fixed 16 Sep 2020. A warning message about deprecated here-doc targets was added.</p>
4972
4973 </dd>
4974 <dt id="make-the-arrow-a-vertical-alignment-token-git-39"><b>make the arrow a vertical alignment token, git #39</b></dt>
4975 <dd>
4976
4977 <p>The -&gt; can now be vertically aligned if a space is placed before it with -wls=&#39;-&gt;&#39;. Added 15 Sep 2020 as part of previous item, 9ac6af6.</p>
4978
4979 </dd>
4980 <dt id="add-flags--bbhb-n--bbsb-n-bbp-n-git-38"><b>add flags -bbhb=n, -bbsb=n, =bbp=n, git #38</b></dt>
4981 <dd>
4982
4983 <p>These flags give control over the opening token of a multiple-line list. They are described in the man pages, perltidy.html. Added 15 Sep 2020 in &quot;added flags -bbhb=n, -bbsb=n, -bbq=n, suggestion git #38&quot;. 9ac6af6.</p>
4984
4985 </dd>
4986 <dt id="Allow-vertical-alignment-of-line-ending-fat-comma"><b>Allow vertical alignment of line-ending fat comma</b></dt>
4987 <dd>
4988
4989 <p>A change was made to allow a &#39;=&gt;&#39; at the end of a line to align vertically, provided that it aligns with two or more other &#39;=&gt;&#39; tokens. This update was 14 Sep 2020, &#39;Allow line-ending &#39;=&gt;&#39; to align vertically&#39;, ea96739.</p>
4990
4991 </dd>
4992 <dt id="fixed-uninitialized-value-reference1"><b>fixed uninitialized value reference</b></dt>
4993 <dd>
4994
4995 <p>The following message was generated when running perltidy on random text:</p>
4996
4997 <pre><code> Use of uninitialized value $K_semicolon in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 16467.</code></pre>
4998
4999 <p>This was fixed 14 Sep 2020, included in &#39;Allow line-ending &#39;=&gt;&#39; to align vertically&#39;, ea96739.</p>
5000
5001 </dd>
5002 <dt id="Do-not-create-a-zero-size-file-by-deleting-semicolons"><b>Do not create a zero size file by deleting semicolons</b></dt>
5003 <dd>
5004
5005 <p>A rule was added to prevent a file consisting of a single semicolon</p>
5006
5007 <pre><code> ;</code></pre>
5008
5009 <p>from becoming a zero length file. This could cause problems with other software. Fixed 13 Sep 2020, &#39;do not create a zero length file by deleting semicolons&#39;, b39195e.</p>
5010
5011 </dd>
5012 <dt id="fixed-uninitialized-value-reference2"><b>fixed uninitialized value reference</b></dt>
5013 <dd>
5014
5015 <p>The following message was generated when running perltidy on random text:</p>
5016
5017 <pre><code> Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 11926.
5018  Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 11936.
5019  Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 11944.</code></pre>
5020
5021 <p>This was fixed 13 Sep 2020 in &#39;fixed unitialized variable problem &#39;, adb2096.</p>
5022
5023 </dd>
5024 <dt id="fixed-uninitialized-value-reference3"><b>fixed uninitialized value reference</b></dt>
5025 <dd>
5026
5027 <p>The following message was generated when running perltidy on random text:</p>
5028
5029 <pre><code> substr outside of string at /home/steve/bin/Perl/Tidy/Tokenizer.pm line 7362.
5030  Use of uninitialized value in concatenation (.) or string at /home/steve/bin/Perl/Tidy/Tokenizer.pm line 7362.</code></pre>
5031
5032 <p>This was fixed 13 Sep 2020 in &#39;fixed unitialized variable problem&#39;, 5bf49a3.</p>
5033
5034 </dd>
5035 <dt id="fixed-uninitialized-value-reference4"><b>fixed uninitialized value reference</b></dt>
5036 <dd>
5037
5038 <p>The following message was generated when running perltidy on random text:</p>
5039
5040 <pre><code> Use of uninitialized value $K_opening in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 16467.</code></pre>
5041
5042 <p>This was fixed 13 Sep 2020 in &#39;fix undefined variable reference&#39;, 1919482.</p>
5043
5044 </dd>
5045 <dt id="hashbang-warning-changed"><b>hashbang warning changed</b></dt>
5046 <dd>
5047
5048 <p>The following snippet generated a warning that there might be a hash-bang after the start of the script.</p>
5049
5050 <pre><code> $x = 2;
5051  #!  sunos does not yet provide a /usr/bin/perl
5052  $script = &quot;$^X $script&quot;;</code></pre>
5053
5054 <p>To prevent this annoyance, the warning is not given unless the first nonblank character after the &#39;#!&#39; is a &#39;/&#39;. Note that this change is just for the warning message. The actual hash bang check does not require the slash.</p>
5055
5056 <p>Fixed 13 Sep 2020, &#39;prevent unnecessary hash-bang warning message&#39; 4f7733e and &#39;improved hash-bang warning filter&#39;, fa84904.</p>
5057
5058 </dd>
5059 <dt id="uninitialized-index-referenced"><b>uninitialized index referenced</b></dt>
5060 <dd>
5061
5062 <p>An unitialized index was referenced when running on a file of randomly generated text:</p>
5063
5064 <pre><code>  Use of uninitialized value $K_oo in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 7259.</code></pre>
5065
5066 <p>This was fixed 12 Sep 2020 in &#39;fixed undefined index&#39;, 616bb88.</p>
5067
5068 </dd>
5069 <dt id="Oops-message-triggered"><b>Oops message triggered</b></dt>
5070 <dd>
5071
5072 <p>The parameter combination -lp -wc triggered an internal bug message from perltidy:</p>
5073
5074 <pre><code> 398: Program bug with -lp.  seqno=77 should be 254 and i=1 should be less than max=-1
5075  713: The logfile perltidy.LOG may contain useful information
5076  713:
5077  713: Oops, you seem to have encountered a bug in perltidy.  Please check the
5078  713: BUGS file at http://perltidy.sourceforge.net.  If the problem is not
5079  713: listed there, please report it so that it can be corrected.  Include the
5080  ...</code></pre>
5081
5082 <p>The problem is that the parameters --line-up-parentheses and --whitespace-cycle=n are not compatible. The fix is to write a message and turn off the -wc parameter when the both occur. This was fixed 8 Sep 2020 in &quot;do not allow -wc and -lp together, can cause bugs&quot;, 7103781.</p>
5083
5084 </dd>
5085 <dt id="Internal-fault-detected-by-perltidy"><b>Internal fault detected by perltidy</b></dt>
5086 <dd>
5087
5088 <p>This snippet after processing with the indicated parameters triggered a Fault message in store-token-to-go due to discontinuous internal index values :</p>
5089
5090 <pre><code>  perltidy --noadd-newlines --space-terminal-semicolon
5091
5092   if ( $_ =~ /PENCIL/ ) { $pencil_flag= 1 } ; ;
5093   $yy=1;</code></pre>
5094
5095 <p>This triggered the message:</p>
5096
5097 <pre><code> ==============================================================================
5098  While operating on input stream with name: &#39;&lt;stdin&gt;&#39;
5099  A fault was detected at line 7472 of sub &#39;Perl::Tidy::Formatter::store_token_to_go&#39;
5100  in file &#39;/home/steve/bin/Perl/Tidy/Formatter.pm&#39;
5101  which was called from line 8298 of sub &#39;Perl::Tidy::Formatter::process_line_of_CODE&#39;
5102  Message: &#39;Unexpected break in K values: 591 != 589+1&#39;
5103  This is probably an error introduced by a recent programming change.
5104  ==============================================================================</code></pre>
5105
5106 <p>The deletion of the extra, spaced, comma had created an extra space in the token array which had not been forseen in the original programming. It was fixed 10 Sep 2020 in &quot;fixed very rare fault found with automated testing&quot;, eb1b1d9.</p>
5107
5108 </dd>
5109 <dt id="Error-parsing-deprecated-variable"><b>Error parsing deprecated $# variable</b></dt>
5110 <dd>
5111
5112 <p>This problem can be illustrated with this two-line snippet:</p>
5113
5114 <pre><code>  $#
5115   eq$,?print&quot;yes\n&quot;:print&quot;no\n&quot;;</code></pre>
5116
5117 <p>Perltidy joined &#39;$#&#39; and &#39;eq&#39; to get $#eq, but should have stopped at the line end to get $# followed by keyword &#39;eq&#39;. (Note that $# is deprecated). This was fixed 11 Sep 2020 in &quot;fixed several fringe parsing bugs found in testing&quot;, 85e01b7.</p>
5118
5119 </dd>
5120 <dt id="Error-message-parsing-a-file-with-angle-brackets-and-ternaries"><b>Error message parsing a file with angle brackets and ternaries</b></dt>
5121 <dd>
5122
5123 <p>This problem can be illustrated with the following test snippet which was not correctly parsed.</p>
5124
5125 <pre><code> print$$ &lt;300?&quot;$$&lt;300\n&quot;:$$&lt;700?&quot;$$&lt;700\n&quot;:$$&lt;2_000?&quot;$$&lt;2,000\n&quot;:$$&lt;10_000?&quot;$$ &lt;10,000\n&quot;:&quot;$$&gt;9,999\n&quot;;</code></pre>
5126
5127 <p>The problem is related to the &#39;&lt;&#39; symbol following the &#39;$$&#39; variable, a possible filehandle, and is similar to a previous bug. The problem was corrected 11 Sep 2020 in &quot;fixed several fringe parsing bugs found in testing&quot;, 85e01b7. The line now correctly formats to</p>
5128
5129 <pre><code> print $$ &lt; 300  ? &quot;$$&lt;300\n&quot;
5130    : $$ &lt; 700    ? &quot;$$&lt;700\n&quot;
5131    : $$ &lt; 2_000  ? &quot;$$&lt;2,000\n&quot;
5132    : $$ &lt; 10_000 ? &quot;$$ &lt;10,000\n&quot;
5133    :               &quot;$$&gt;9,999\n&quot;;</code></pre>
5134
5135 </dd>
5136 <dt id="code-crash-with-cuddled-else-formatting-on-unbalanced-files"><b>code crash with cuddled-else formatting on unbalanced files</b></dt>
5137 <dd>
5138
5139 <p>A file with incorrect bracing which effectively gave negative indentation caused a crash when a stack was referenced with a negative index. The problem was fixed 8 Sept 2020 in &quot;convert array to hash to avoid trouble with neg levels in bad files&quot;, a720e0d.</p>
5140
5141 </dd>
5142 <dt id="error-message-Unterminated-angle-operator"><b>error message &#39;Unterminated angle operator?&#39;</b></dt>
5143 <dd>
5144
5145 <p>This error can be demonstrated with this line.</p>
5146
5147 <pre><code>  print $i &lt;10 ? &quot;yes&quot; : &quot;no&quot;;</code></pre>
5148
5149 <p>Perl has some strange parsing rules near a possible filehandle, and they change over time. The &#39;&lt;&#39; here is a less than symbol, but perltidy expected that it might be the start of an angle operator, based on the old rules, and gave a warning. The formatting was still correct, but the warning was confusing. This has been fixed 8 Sep 2020 in &#39;remove confusing warning message&#39;, 0a4d725.</p>
5150
5151 </dd>
5152 <dt id="Line-broken-after-here-target"><b>Line broken after here target</b></dt>
5153 <dd>
5154
5155 <p>This problem is illustrated with the following snippet</p>
5156
5157 <pre><code>  $sth= $dbh-&gt;prepare (&lt;&lt;&quot;END_OF_SELECT&quot;) or die &quot;Couldn&#39;t prepare SQL&quot; ;
5158       SELECT COUNT(duration),SUM(duration)
5159       FROM logins WHERE username=&#39;$user&#39;
5160   END_OF_SELECT</code></pre>
5161
5162 <p>When run with a short line length it got broken after the here target, causing an error. This was due to a recent program change and fixed 7 Sep 2020 in &#39;fixed bug where long line with here target got broken&#39;, 8f7e4cb.</p>
5163
5164 </dd>
5165 <dt id="undefined-variable-named-test2"><b>undefined variable named &#39;test2&#39;</b></dt>
5166 <dd>
5167
5168 <p>An uninitialized value was being referenced and triggered this message:</p>
5169
5170 <pre><code> undefined test2, i_opening=5, max=18, caller=Perl::Tidy::Formatter ./perltidy-20200907.pl 13465
5171  Use of uninitialized value $test2 in numeric eq (==) at ./perltidy-20200907.pl line 19692.</code></pre>
5172
5173 <p>Fixed 8 Sep 2020 in &#39;fixed rare problem with stored index values for -lp option&#39;, 4147c8c.</p>
5174
5175 </dd>
5176 <dt id="Line-order-switched-at-start-of-quoted-text"><b>Line order switched at start of quoted text</b></dt>
5177 <dd>
5178
5179 <p>This problem arose in several scripts involving the parameter --line-up-parentheses pluse one or more of the vertical tightness flags. It can be illustrated with the following snippet:</p>
5180
5181 <pre><code>    perltidy --line-up-parentheses --paren-vertical-tightness=1
5182
5183     if (
5184         ( $name, $chap ) =
5185         $cur_fname =~ m!^Bible/
5186           .*?/          # testament
5187           .*?/          # range of books
5188           (.*?)/        # book name
5189           .*?           # optional range of verses
5190           (\d+)$!x
5191       )
5192     {
5193         $cur_name = &quot;$name $chap&quot;;
5194     }</code></pre>
5195
5196 <p>This gave</p>
5197
5198 <pre><code>    if (( $name, $chap ) =
5199           .*?/          # testament
5200         $cur_fname =~ m!^Bible/
5201           .*?/          # range of books
5202           (.*?)/        # book name
5203           .*?           # optional range of verses
5204           (\d+)$!x
5205       )
5206     {
5207         $cur_name = &quot;$name $chap&quot;;
5208     }</code></pre>
5209
5210 <p>Notice the incorrect line order. The problem was an incorrect order of operations in the vertical aligner flush, leaving a line stranded and coming out in the wrong order. This was fixed 11 Sep 2020.</p>
5211
5212 </dd>
5213 <dt id="crash-due-to-bad-index-named-j_terminal_match"><b>crash due to bad index named &#39;$j_terminal_match&#39;</b></dt>
5214 <dd>
5215
5216 <p>This crash was due to an index error which caused a non-existent object to be referenced. The problem is fixed 2020-09-07 in &quot;fix problem of undefined values involving j_terminal_match&quot;, c5bfa77. The particular parameters which caused this were:</p>
5217
5218 <pre><code>    --noadd-newlines --nowant-left-space=&#39;=&#39; </code></pre>
5219
5220 </dd>
5221 <dt id="an-issue-with-the--x-flag"><b>an issue with the -x flag</b></dt>
5222 <dd>
5223
5224 <p>This is not a bug but did take some time to resolve. The problem was reduced to the following script run with the -x flag (--look-for-hash-bang)</p>
5225
5226 <pre><code> print(SCRIPT$headmaybe . &lt;&lt;EOB . &lt;&lt;&#39;EOF&#39; .$tailmaybe),$!;
5227  #!$wd/perl
5228  EOB
5229  print &quot;\$^X is $^X, \$0 is $0\n&quot;;
5230  EOF</code></pre>
5231
5232 <p>The resulting file had a syntax error (here-doc target EOB changed).</p>
5233
5234 <pre><code> print(SCRIPT$headmaybe . &lt;&lt;EOB . &lt;&lt;&#39;EOF&#39; .$tailmaybe),$!;
5235  #!$wd/perl
5236  EOB print &quot;\$^X is $^X, \$0 is $0\n&quot;;
5237  EOF</code></pre>
5238
5239 <p>The problem is that the -x flag tells perltidy not to start parsing until it sees a line starting with &#39;#!&#39;, which happens to be in a here-doc in this case.</p>
5240
5241 <p>A warning was added to the manual 7 Sept 2020 in &quot;add warning about inappropriate -x flag&quot;, fe66743.</p>
5242
5243 </dd>
5244 <dt id="error-parsing-sub-signature"><b>error parsing sub signature</b></dt>
5245 <dd>
5246
5247 <p>This problem was reduced to the following snippet:</p>
5248
5249 <pre><code> substr
5250  (
5251   $#
5252  )</code></pre>
5253
5254 <p>The deprecated variable &#39;$#&#39; was being parsed incorrectly, and this was due to an error in which the word &#39;substr&#39; followed by a paren was taken as the start of a sub signature. The problem was fixed 8 Sep 2020 in &#39;fix problem parsing sub prototypes&#39; 569e05f. The code</p>
5255
5256 <pre><code>  $container_type =~ /^sub/;</code></pre>
5257
5258 <p>was corrected to be</p>
5259
5260 <pre><code>  $container_type =~ /^sub\b/;</code></pre>
5261
5262 </dd>
5263 <dt id="uninitialized-value-message-found-7-Sep-2020"><b>uninitialized value message, found 7 Sep 2020</b></dt>
5264 <dd>
5265
5266 <p>Unitialized values were referenced. An index was not being tested. Fixed 8 Sep 2020 in &quot;fix undefined variable&quot;, 9729965.</p>
5267
5268 <pre><code> Use of uninitialized value $Kon in array element at /home/steve/bin/Perl/Tidy/Formatter.pm line 4022.
5269  Use of uninitialized value $Kon in array element at /home/steve/bin/Perl/Tidy/Formatter.pm line 4023.
5270  Use of uninitialized value $Ko in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 4023.</code></pre>
5271
5272 </dd>
5273 </dl>
5274
5275 <h1 id="Open-Issues">Open Issues</h1>
5276
5277 <p>These are known issues which have not been fixed.</p>
5278
5279 <dl>
5280
5281 <dt id="lexical-subs-not-fully-supported"><b>lexical subs not fully supported</b></dt>
5282 <dd>
5283
5284 <p>Basic parsing of lexical subs works but some aspects of lexical subs are not yet functional. One of these is that unlike regular subs, lexical subs can override names of builtin functions.</p>
5285
5286 <p>First consider the following snippet</p>
5287
5288 <pre><code>  sub s {
5289     my $arg=$_[0];
5290     print &quot;s called with arg $arg\n&quot;;
5291   }
5292   s(1);
5293   s(2);</code></pre>
5294
5295 <p>The &#39;s&#39; in the two last lines is the builtin s function, not the sub. Both perltidy and perl make the same assumption here. This program happens to still run but prints nothing. It will not run if the last semicolon is removed.</p>
5296
5297 <p>Now consider the following snippet in which the sub has a preceding &#39;my&#39;</p>
5298
5299 <pre><code>  use feature &#39;lexical_subs&#39;, &#39;signatures&#39;;
5300   my sub s {
5301     my $arg=$_[0];
5302     print &quot;s called with arg $arg\n&quot;;
5303   }
5304   s(1);
5305   s(2);</code></pre>
5306
5307 <p>The builtin function &#39;s&#39; is replaced by the sub s here, and the program runs. Perltidy will format this but it is assuming that the s in the two last lines are the builtin s function. If the last semicolon is removed, there will be an formatting error. So perltidy and perl make different assumptions in this case.</p>
5308
5309 <p>Another issue is that perltidy does not yet remember the extent of the scope of a lexical sub.</p>
5310
5311 </dd>
5312 <dt id="issues-with-paren-less-calls"><b>issues with paren-less calls</b></dt>
5313 <dd>
5314
5315 <p>Consider the following snippet:</p>
5316
5317 <pre><code>  use Test::More;
5318   ok open($stdin, &quot;&lt;&amp;&quot;, $1), &#39;open ... &quot;&lt;&amp;&quot;, $magical_fileno&#39;, ||  _diag $!;</code></pre>
5319
5320 <p>Note the unusual situation of a comma followed by an &#39;||&#39;. Perltidy will format this satisfactorily but it will write an error message. The syntax is correct, however. Perl knows the prototype of the &#39;ok&#39; function, which is called here without parens, so the last comma marks the last arg and is needed to keep the || from attaching to the last arg.</p>
5321
5322 <p>Full support of peren-less calls will probably never be implemented in perltidy because it would require that it parse all of the modules used to find the prototypes. This would make it impossible to run perltidy on small snippets of code from within an editor.</p>
5323
5324 <p>The problem can be avoid if parens are used:</p>
5325
5326 <pre><code>  ok ( open($stdin, &quot;&lt;&amp;&quot;, $1), &#39;open ... &quot;&lt;&amp;&quot;, $magical_fileno&#39;) ||  _diag $!;</code></pre>
5327
5328 </dd>
5329 <dt id="multiple-sub-paren-calls"><b>multiple sub paren calls</b></dt>
5330 <dd>
5331
5332 <p>Perltidy currently flags as an error a closing paren followed by an opening paren, as in the following</p>
5333
5334 <pre><code>  $subsubs[0]()(0)</code></pre>
5335
5336 <p>This syntax is ok. The example is from test &#39;current_sub.t&#39; in perl5.31.</p>
5337
5338 </dd>
5339 </dl>
5340
5341
5342 </body>
5343
5344 </html>
5345
5346