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-20210625">Issues fixed after release 20210625</a></li>
  16   <li><a href="#Issues-fixed-after-release-20210402">Issues fixed after release 20210402</a></li>
  17   <li><a href="#Issues-fixed-after-release-20210111">Issues fixed after release 20210111</a></li>
  18   <li><a href="#Issues-fixed-after-release-20201207">Issues fixed after release 20201207</a></li>
  19   <li><a href="#Issues-fixed-after-release-20201202">Issues fixed after release 20201202</a></li>
  20   <li><a href="#Issues-fixed-after-release-20201001">Issues fixed after release 20201001</a></li>
  21   <li><a href="#Issues-fixed-after-release-20200907">Issues fixed after release 20200907</a></li>
  22   <li><a href="#Open-Issues">Open Issues</a></li>
  23 </ul>
  24
  25 <h1 id="Issues-fixed-after-release-20210625">Issues fixed after release 20210625</h1>
  26
  27 <dl>
  28
  29 <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>
  30 <dd>
  31
  32 <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>
  33
  34 <pre><code>    # perltidy -sil=1
  35     $$d{&quot;day_name&quot;} = [
  36         [
  37             &quot;lundi&quot;,    &quot;mardi&quot;,  &quot;mercredi&quot;, &quot;jeudi&quot;,
  38             &quot;vendredi&quot;, &quot;samedi&quot;, &quot;dimanche&quot;
  39         ]
  40     ];</code></pre>
  41
  42 <p>With welding we get:</p>
  43
  44 <pre><code>    # -sil=1 -wn
  45     $$d{&quot;day_name&quot;} = [ [
  46         &quot;lundi&quot;,    &quot;mardi&quot;,  &quot;mercredi&quot;, &quot;jeudi&quot;,
  47         &quot;vendredi&quot;, &quot;samedi&quot;, &quot;dimanche&quot;
  48     ] ];</code></pre>
  49
  50 <p>With -bbsb=3 (--break-before-square-brackets) we get:</p>
  51
  52 <pre><code>    # -sil=1 -bbsb=3
  53     $$d{&quot;day_name&quot;} =
  54       [
  55         [
  56             &quot;lundi&quot;,    &quot;mardi&quot;,  &quot;mercredi&quot;, &quot;jeudi&quot;,
  57             &quot;vendredi&quot;, &quot;samedi&quot;, &quot;dimanche&quot;
  58         ]
  59       ];</code></pre>
  60
  61 <p>So far, so good. But for the combination -bbsb=3 -wn we get</p>
  62
  63 <pre><code>    # OLD: ERROR
  64     # -sil=1 -bbsb=3 -wn
  65     $$d{&quot;day_name&quot;} = [ [
  66         &quot;lundi&quot;,    &quot;mardi&quot;,  &quot;mercredi&quot;, &quot;jeudi&quot;,
  67         &quot;vendredi&quot;, &quot;samedi&quot;, &quot;dimanche&quot;
  68     ] ];</code></pre>
  69
  70 <p>which is incorrect because it ignors the -bbsb flag. The corrected result is</p>
  71
  72 <pre><code>    # NEW: OK
  73     # -sil=1 -bbsb=3 -wn
  74     $$d{&quot;day_name&quot;} =
  75       [ [
  76         &quot;lundi&quot;,    &quot;mardi&quot;,  &quot;mercredi&quot;, &quot;jeudi&quot;,
  77         &quot;vendredi&quot;, &quot;samedi&quot;, &quot;dimanche&quot;
  78       ] ];</code></pre>
  79
  80 <p>This update fixes case b1173. It works for any number of welded containers, and the -bbxxi=n flags also work correctly.</p>
  81
  82 <p>16 Jul 2021.</p>
  83
  84 </dd>
  85 <dt id="Fix-problem-with-side-comment-after-pattern"><b>Fix problem with side comment after pattern</b></dt>
  86 <dd>
  87
  88 <p>Testing with randomly placed side comments produced an error illustrated with the following snippet:</p>
  89
  90 <pre><code>    testit
  91     /A (*THEN) X | B (*THEN) C/x#sc#
  92     ,
  93     &quot;Simple (*THEN) test&quot;
  94     ;</code></pre>
  95
  96 <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>
  97
  98 <p>13 Jul 2021, 8b36de8.</p>
  99
 100 </dd>
 101 <dt id="Fix-problem-with-side-comment-after-pointer-part-3"><b>Fix problem with side comment after pointer, part 3</b></dt>
 102 <dd>
 103
 104 <p>This update fixes some incorrect tokenization produced by a side comment placed between a pointer and a bareword as in this snippet:</p>
 105
 106 <pre><code>    sub tzoffset {};
 107
 108     ...
 109
 110     my $J
 111     +=
 112     (
 113     $self
 114     -&gt;#sc
 115     tzoffset
 116     / (
 117     24
 118     *
 119     3600
 120     )
 121     );</code></pre>
 122
 123 <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>
 124
 125 <p>13 Jul 2021, cab7ed3.</p>
 126
 127 </dd>
 128 <dt id="Avoid-line-breaks-before-a-slash-in-certain-cases"><b>Avoid line breaks before a slash in certain cases</b></dt>
 129 <dd>
 130
 131 <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>
 132
 133 <p>11 Jul 2021, 7afee47.</p>
 134
 135 </dd>
 136 <dt id="Fix-error-parsing-sub-attributes-with-side-comment"><b>Fix error parsing sub attributes with side comment</b></dt>
 137 <dd>
 138
 139 <p>Testing with side comments produced an error in the following snippet:</p>
 140
 141 <pre><code>    sub plugh () :#
 142       Ugly(&#39;\(&quot;) : Bad;</code></pre>
 143
 144 <p>This is fixed in this update, case c038.</p>
 145
 146 <p>11 Jul 2021, 80f2a3a.</p>
 147
 148 </dd>
 149 <dt id="Fix-case-b1172-a-failure-to-converge"><b>Fix case b1172, a failure to converge</b></dt>
 150 <dd>
 151
 152 <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>
 153
 154 <p>10 Jul 2021, 47e7f9b.</p>
 155
 156 </dd>
 157 <dt id="Avoid-line-breaks-before-a-slash-in-certain-cases1"><b>Avoid line breaks before a slash in certain cases</b></dt>
 158 <dd>
 159
 160 <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>
 161
 162 <p>This fixes case c039.</p>
 163
 164 <p>10 Jul 2021, 461199c.</p>
 165
 166 </dd>
 167 <dt id="Removed-warning-message-if-ending-in-code-skipping-section"><b>Removed warning message if ending in code skipping section</b></dt>
 168 <dd>
 169
 170 <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>
 171
 172 <p>10 Jul 2021, 461199c.</p>
 173
 174 </dd>
 175 <dt id="Improve-logic-for-distinguishing-a-pattern-vs-a-division"><b>Improve logic for distinguishing a pattern vs a division</b></dt>
 176 <dd>
 177
 178 <p>Testing with side comments produced the following snippet which caused a error due to the side comment on the &#39;/&#39;</p>
 179
 180 <pre><code>    $bond_str
 181     =
 182     VERY_WEAK #sc#
 183     / #sc#
 184     1.05
 185     ;</code></pre>
 186
 187 <p>Several related examples were found in which side comments triggered errors. For example</p>
 188
 189 <pre><code>    ok
 190     /[^\s]+/#sc#
 191     ,
 192     &#39;m/[^\s]/ utf8&#39;
 193     ;</code></pre>
 194
 195 <p>This update fixes these problems, case c040.</p>
 196
 197 <p>9 Jul 2021, ffe4351.</p>
 198
 199 </dd>
 200 <dt id="Fix-problem-caused-by-side-comment-after"><b>Fix problem caused by side comment after ++</b></dt>
 201 <dd>
 202
 203 <p>Testing with side comments produced an incorrect error message for this snippet:</p>
 204
 205 <pre><code>    xxx
 206     ++#
 207     $test,
 208     Internals::SvREADONLY( %$copy) ,
 209     &quot;cloned hash restricted?&quot; ;</code></pre>
 210
 211 <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>
 212
 213 <p>8 Jul 2021, 20cc9a0.</p>
 214
 215 </dd>
 216 <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>
 217 <dd>
 218
 219 <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>
 220
 221 <pre><code>    @ret
 222     =
 223     $o
 224     -&gt;#
 225     SUPER&#39;method
 226     (
 227     &#39;whatever&#39;
 228     )
 229     ;</code></pre>
 230
 231 <p>This is fixed in this update, case c041.</p>
 232
 233 <p>7 Jul 2021, 1806772.</p>
 234
 235 </dd>
 236 <dt id="Fix-problem-caused-by-side-comment-after-pointer"><b>Fix problem caused by side comment after pointer</b></dt>
 237 <dd>
 238
 239 <p>The following test script</p>
 240
 241 <pre><code>    is(
 242     $one
 243     -&gt;#sc#
 244     package
 245     ,
 246     &quot;bar&quot;
 247     ,
 248     &quot;Got package&quot;
 249     )
 250     ;</code></pre>
 251
 252 <p>Caused the following error message:</p>
 253
 254 <pre><code>  4: package
 255      ^
 256   found package where operator expected</code></pre>
 257
 258 <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>
 259
 260 <p>This is fixed in this update, case c037, 96f2ebb.</p>
 261
 262 </dd>
 263 <dt id="Fix-error-parsing-and-similar-combinations"><b>Fix error parsing &#39;%#&#39; and similar combinations</b></dt>
 264 <dd>
 265
 266 <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>
 267
 268 <pre><code>    # this is a valid program, &#39;%#&#39; is a punctuation variable
 269     %# = ( foo =&gt; &#39;bar&#39;, baz =&gt; &#39;buz&#39; );
 270     print keys(%#), &quot;\n&quot;;
 271
 272     # but this is a syntax error (space before # makes a side comment)
 273     # (perltidy was ignoring the space and forming &#39;%#&#39; here)
 274     % # = ( foo =&gt; &#39;bar&#39;, baz =&gt; &#39;buz&#39; );
 275     print keys(%#), &quot;\n&quot;;
 276
 277     # this is a valid program, &#39;@#&#39; is a punctuation variable
 278     @# = ( foo , &#39;bar&#39;, baz , &#39;buz&#39; );
 279     print @#, &quot;\n&quot;;
 280
 281     # this is a valid program, the space makes the &#39;#&#39; a side comment
 282     # perltidy formed %# here, causing an error
 283     % #
 284     var = ( foo =&gt; &#39;bar&#39;, baz =&gt; &#39;buz&#39; );
 285     print keys(%var), &quot;\n&quot;;</code></pre>
 286
 287 <p>This fixes case c036.</p>
 288
 289 <p>6 Jul 2021, e233d41.</p>
 290
 291 </dd>
 292 <dt id="Fix-error-parsing"><b>Fix error parsing &#39;&amp;#&#39;</b></dt>
 293 <dd>
 294
 295 <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>
 296
 297 <pre><code>    print$my_bag
 298     &amp;#sc#
 299     $your_bag
 300     ,
 301     &quot;\n&quot;
 302     ;</code></pre>
 303
 304 <p>This update fixes this issue, c033.</p>
 305
 306 <p>5 Jul 2021, 0d784e0.</p>
 307
 308 </dd>
 309 <dt id="Fix-error-parsing-format-statement"><b>Fix error parsing format statement</b></dt>
 310 <dd>
 311
 312 <p>The following test script caused an error when perltidy took &#39;format&#39; to start a format statement.</p>
 313
 314 <pre><code>    my$ascii#sc#
 315     =#sc#
 316     $formatter#sc#
 317     -&gt;#sc#
 318     format#sc#
 319     (#sc#
 320     $html#sc#
 321     )#sc#
 322     ;#sc#</code></pre>
 323
 324 <p>This was fixed by requiring a format statement to begin where a new statement can occur. This fixes issue c035.</p>
 325
 326 <p>5 Jan 2021, 2ef16fb.</p>
 327
 328 </dd>
 329 <dt id="Fix-some-incorrect-error-messages-due-to-side-comments"><b>Fix some incorrect error messages due to side comments</b></dt>
 330 <dd>
 331
 332 <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>
 333
 334 <pre><code>    $Msg#sc#
 335     -&gt;#sc#
 336     $field#sc#
 337     (#sc#
 338     )#sc#
 339     ;#sc#</code></pre>
 340
 341 <p>This update fixes cases c029 and c030.</p>
 342
 343 <p>4 Jul 2021, caffc2c.</p>
 344
 345 </dd>
 346 <dt id="Fix-undefined-var-ref-involving---format-skipping"><b>Fix undefined var ref involving --format-skipping</b></dt>
 347 <dd>
 348
 349 <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>
 350
 351 <pre><code>    #!/usr/bin/perl
 352     #&lt;&lt;&lt;
 353         my $ra= (
 354             [ &#39;Shine&#39;, 40 ], [ &#39;Specular&#39;, [ 1, 1, 0.3, 0 ] ] );
 355     #&lt;&lt;&lt;
 356     ...</code></pre>
 357
 358 <p>The conditions for this to happen are:</p>
 359
 360 <pre><code>  (1) format skipping (#&lt;&lt;&lt;) begins before the first line of code, and
 361   (2) the format skipping section contains the two successive characters &#39;, [&#39;.</code></pre>
 362
 363 <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>
 364
 365 <p>This update fixes this problem.</p>
 366
 367 <p>4 Jul 2021, 82916fe.</p>
 368
 369 </dd>
 370 <dt id="Check-for-side-comment-within-package-statement"><b>Check for side comment within package statement</b></dt>
 371 <dd>
 372
 373 <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>
 374
 375 <pre><code>    package double # side comment
 376     ;</code></pre>
 377
 378 <p>This update fixes this. 3 Jul 2021, c00059a.</p>
 379
 380 </dd>
 381 <dt id="Fix-problem-with--comma-arrow-breakpoint-n-flag"><b>Fix problem with -comma-arrow-breakpoint=n flag</b></dt>
 382 <dd>
 383
 384 <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>
 385
 386 <p>1 Jul 2021, 021b938.</p>
 387
 388 </dd>
 389 <dt id="Fix-a-formatting-instability"><b>Fix a formatting instability</b></dt>
 390 <dd>
 391
 392 <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>
 393
 394 <p>1 Jul 2021, 021b938.</p>
 395
 396 </dd>
 397 <dt id="Fixed-use-of-uninitialized-value"><b>Fixed use of uninitialized value</b></dt>
 398 <dd>
 399
 400 <p>The previous Tokenizer update caused the use of an unitialized value when run on case b1053:</p>
 401
 402 <pre><code> Use of uninitialized value $next_nonblank_token in pattern match (m//) at /home/steve/bin/Perl/Tidy/Tokenizer.pm line 7589.
 403  Use of uninitialized value $nn_nonblank_token in pattern match (m//) at /home/steve/bin/Perl/Tidy/Tokenizer.pm line 3723.
 404  b1053 converged on iteration 2</code></pre>
 405
 406 <p>This update fixes this.</p>
 407
 408 <p>1 Jul 2021, ea139bd.</p>
 409
 410 </dd>
 411 <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>
 412 <dd>
 413
 414 <p>In the following example</p>
 415
 416 <pre><code>    print &quot;not &quot; unless ref +(
 417         map {
 418             sub : lvalue { &quot;a&quot; }
 419         } 1
 420     )[0] eq &quot;CODE&quot;;</code></pre>
 421
 422 <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>
 423
 424 <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>
 425
 426 <pre><code>    my $xx = 0;
 427     sub : {
 428         $xx++;
 429         print &quot;looping with label sub:, a=$xx\n&quot;;
 430         if ( $xx &lt; 10 ) { goto &quot;sub&quot; }
 431     }</code></pre>
 432
 433 <p>In this case, the goto statement needs quotes around &quot;sub&quot; because it is a keyword.</p>
 434
 435 <p>29 Jun 2021, d5fb3d5.</p>
 436
 437 </dd>
 438 <dt id="Minor-adjustments-to-improve-formatting-stability"><b>Minor adjustments to improve formatting stability</b></dt>
 439 <dd>
 440
 441 <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>
 442
 443 <p>28 Jun 2021, e1f22e0.</p>
 444
 445 </dd>
 446 <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>
 447 <dd>
 448
 449 <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>
 450
 451 <p>28 Jun 2021, 1b3c5e9.</p>
 452
 453 </dd>
 454 <dt id="Minor-optimization"><b>Minor optimization</b></dt>
 455 <dd>
 456
 457 <p>Added a quick check to bypass a needless sub call.</p>
 458
 459 <p>26 Jan 2021, e7822df.</p>
 460
 461 </dd>
 462 <dt id="Eliminate-token-variable-_LEVEL_TRUE_"><b>Eliminate token variable _LEVEL_TRUE_</b></dt>
 463 <dd>
 464
 465 <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>
 466
 467 <p>26 Jun 2021, 1f4f78c.</p>
 468
 469 </dd>
 470 <dt id="Eliminate-token-variable-_CONTAINER_ENVIRONMENT_"><b>Eliminate token variable _CONTAINER_ENVIRONMENT_</b></dt>
 471 <dd>
 472
 473 <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>
 474
 475 <p>26 Jun 2021, 300ca1e.</p>
 476
 477 </dd>
 478 </dl>
 479
 480 <h1 id="Issues-fixed-after-release-20210402">Issues fixed after release 20210402</h1>
 481
 482 <dl>
 483
 484 <dt id="Release-20210625"><b>Release 20210625</b></dt>
 485 <dd>
 486
 487 <p>24 Jun 2021, a4ff53d.</p>
 488
 489 </dd>
 490 <dt id="Adjust-tolerances-to-fix-some-unstable-edge-cases"><b>Adjust tolerances to fix some unstable edge cases</b></dt>
 491 <dd>
 492
 493 <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>
 494
 495 <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>
 496
 497 <p>There are no other known cases of formatting instability at the present time, but testing with random input parameters will continue.</p>
 498
 499 <p>21 Jun 2021, 1b682fd.</p>
 500
 501 </dd>
 502 <dt id="Adjust-tolerances-to-fix-some-unstable-edge-cases1"><b>Adjust tolerances to fix some unstable edge cases</b></dt>
 503 <dd>
 504
 505 <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>
 506
 507 <p>This fixes cases b1137 b1149 b1150 b1155 b1158 b1159 b1160 b1161 b1166 b1167 b1168.</p>
 508
 509 <p>19 Jun 2021, 4d4970a.</p>
 510
 511 </dd>
 512 <dt id="Added-flag--atnl---add-terminal-newline-see-git-58"><b>Added flag -atnl, --add-terminal-newline, see git #58</b></dt>
 513 <dd>
 514
 515 <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>
 516
 517 <p>Negating this flag may be useful for manipulating one-line scripts intended for use on a command line.</p>
 518
 519 <p>This update also removes the description of the obsolete --check-syntax flag from the man pages and help text.</p>
 520
 521 <p>18 Jun 2021, 6f83170.</p>
 522
 523 </dd>
 524 <dt id="Allow---delete-side-comments-to-work-with--nanl"><b>Allow --delete-side-comments to work with -nanl</b></dt>
 525 <dd>
 526
 527 <p>The -nanl flag (--noadd-newlines) was preventing side comments from being deleted, for example:</p>
 528
 529 <pre><code>    # perltidy -dsc -nanl
 530     calc()    # side comment</code></pre>
 531
 532 <p>The same issue was happening for --delete-closing-side comments. This has been fixed.</p>
 533
 534 <p>18 Jun 2021, dbfd802.</p>
 535
 536 </dd>
 537 <dt id="Update-welding-rule-to-avoid-unstable-states"><b>Update welding rule to avoid unstable states</b></dt>
 538 <dd>
 539
 540 <p>Testing with random input parameters produced a formatting instability involving an unusual parameter combination:</p>
 541
 542 <pre><code>    --noadd-whitespace
 543     --break-before-paren=3
 544     --continuation-indentation=8
 545     --delete-old-whitespace
 546     --line-up-parentheses
 547     --weld-nested-containers</code></pre>
 548
 549 <p>and the following code</p>
 550
 551 <pre><code>        if(defined$hints{family}){
 552             @infos=({
 553                      family=&gt;$hints{family},
 554                      socktype=&gt;$hints{socktype},
 555                      protocol=&gt;$hints{protocol},
 556             });
 557         }</code></pre>
 558
 559 <p>This update fixes the problem, case b1162.</p>
 560
 561 <p>18 Jun 2021, 76873ea.</p>
 562
 563 </dd>
 564 <dt id="Convert-some-weld-sub-calls-to-hash-lookups"><b>Convert some weld sub calls to hash lookups</b></dt>
 565 <dd>
 566
 567 <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>
 568
 569 <p>17 Jun 2021, 1691013.</p>
 570
 571 </dd>
 572 <dt id="Update-LineSink.pm-to-allow-undefined-line-endings"><b>Update LineSink.pm to allow undefined line endings</b></dt>
 573 <dd>
 574
 575 <p>This update is necessary to eventually prevent an unwanted terminal newline being added to a file.</p>
 576
 577 <p>17 Jun 2021, 2600533.</p>
 578
 579 </dd>
 580 <dt id="Fix-incorrect-sub-call"><b>Fix incorrect sub call</b></dt>
 581 <dd>
 582
 583 <p>This fixes an incorrect call which could cause an incorrect weld.</p>
 584
 585 <p>16 Jun 2021, 068a28b.</p>
 586
 587 </dd>
 588 <dt id="Add---code-skipping-option-see-git-65"><b>Add --code-skipping option, see git #65</b></dt>
 589 <dd>
 590
 591 <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>
 592
 593 <p>16 Jun 2021, 99ec876.</p>
 594
 595 </dd>
 596 <dt id="Handle-nested-print-format-blocks"><b>Handle nested print format blocks</b></dt>
 597 <dd>
 598
 599 <p>Perltidy was producing an error at nested print format blocks, such as</p>
 600
 601 <pre><code>    format NEST =
 602     @&lt;&lt;&lt;
 603     {
 604         my $birds = &quot;birds&quot;;
 605         local *NEST = *BIRDS{FORMAT};
 606         write NEST;
 607         format BIRDS =
 608     @&lt;&lt;&lt;&lt;&lt;
 609     $birds;
 610     .
 611     &quot;nest&quot;
 612       }
 613     .</code></pre>
 614
 615 <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>
 616
 617 <p>13 Jun 2021.</p>
 618
 619 </dd>
 620 <dt id="Allow-stacked-labels-without-spaces"><b>Allow stacked labels without spaces</b></dt>
 621 <dd>
 622
 623 <p>When labels are stacked in a single line, such as</p>
 624
 625 <p>A:B:C:</p>
 626
 627 <p>the default is to space them:</p>
 628
 629 <p>A: B: C:</p>
 630
 631 <p>This update allows the spaces to be removed if desired:</p>
 632
 633 <p># perltidy -naws -dws A:B:C:</p>
 634
 635 <p>13 Jun 2021, c2a63b2</p>
 636
 637 </dd>
 638 <dt id="Fix-edge-cases-of-instability-involving--wn--lp"><b>Fix edge cases of instability involving -wn -lp</b></dt>
 639 <dd>
 640
 641 <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>
 642
 643 <p>12 Jun 2021, 125494b.</p>
 644
 645 </dd>
 646 <dt id="Remove-incorrect-warning-at-repeated-function-paren-call"><b>Remove incorrect warning at repeated function paren call</b></dt>
 647 <dd>
 648
 649 <p>This update removes an incorrect error messagge at the construct &#39;)(&#39;. To illustrate, the following is a valid program:</p>
 650
 651 <pre><code>    my @words = qw(To view this email as a web page go here);
 652     my @subs;
 653     push @subs, sub { my $i=shift; $i %= @words; print &quot;$words[$i] &quot;; return $subs[0]};
 654     $subs[0](0)(1)(2)(3)(4)(5)(6)(7)(8)(9)(10)(11);
 655     print &quot;\n&quot;;</code></pre>
 656
 657 <p>However perltidy was giving an error message at the &#39;)(&#39; combination, which is unusual in perl scripts. This update fixes this.</p>
 658
 659 <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>
 660
 661 <p>This update is in Tokenizer.pm and fixes case c017.</p>
 662
 663 <p>6 Jun 2021, 6551d65.</p>
 664
 665 </dd>
 666 <dt id="Add-warning-when-lexical-sub-names-match-some-builtins"><b>Add warning when lexical sub names match some builtins</b></dt>
 667 <dd>
 668
 669 <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>
 670
 671 <pre><code>    use feature qw(lexical_subs);
 672     use warnings; no warnings &quot;experimental::lexical_subs&quot;;
 673     {
 674       my sub y { print &quot;Hello from y: $_[0]\n&quot;; }
 675       y(1);
 676     }</code></pre>
 677
 678 <p>6 Jun 2021, 32729fb.</p>
 679
 680 </dd>
 681 <dt id="Minor-cleanups"><b>Minor cleanups</b></dt>
 682 <dd>
 683
 684 <p>This update fixes a case of formatting instability recently found with random testing. It also does some minor coding cleanups.</p>
 685
 686 <p>This fixes case b1139.</p>
 687
 688 <p>5 Jun 2021, b8527ab.</p>
 689
 690 </dd>
 691 <dt id="Revised-data-structures-for-welding"><b>Revised data structures for welding</b></dt>
 692 <dd>
 693
 694 <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>
 695
 696 <p>4 Jun 2021, 4a886c8.</p>
 697
 698 </dd>
 699 <dt id="improved-treatment-of-lexical-subs"><b>improved treatment of lexical subs</b></dt>
 700 <dd>
 701
 702 <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>
 703
 704 <p>For example, running the previous version of perltidy on the following:</p>
 705
 706 <pre><code>    use feature qw(lexical_subs);
 707     use warnings; no warnings &quot;experimental::lexical_subs&quot;;
 708     {
 709         my sub hello { print &quot;Hello from hello1\n&quot; }
 710         {
 711             my sub hello { print &quot;Hello from hello2\n&quot; }
 712             hello();
 713         }
 714         hello();
 715     }
 716     {
 717         my sub hello { print &quot;Hello from hello3\n&quot; }
 718         hello();
 719     }</code></pre>
 720
 721 <p>gave the (incorrect) error message:</p>
 722
 723 <pre><code>    6: already saw definition of &#39;sub hello&#39; in package &#39;main&#39; at line 4
 724     12: already saw definition of &#39;sub hello&#39; in package &#39;main&#39; at line 6</code></pre>
 725
 726 <p>This update fixes that.</p>
 727
 728 <p>1 Jun 2021, 85ecb7a.</p>
 729
 730 </dd>
 731 <dt id="add-v-string-underscores-warn-of-leading-commas"><b>add v-string underscores; warn of leading commas</b></dt>
 732 <dd>
 733
 734 <p>This update cleans up a couple of open issues in the tokenizer.</p>
 735
 736 <p>A warning message will be produced for a list which begins with a comma:</p>
 737
 738 <pre><code>            my %string = (
 739               ,       &quot;saddr&quot;,    $stest,  &quot;daddr&quot;,
 740               $dtest, &quot;source&quot;,   $sname,  &quot;dest&quot;)</code></pre>
 741
 742 <p>This warning had been temporarily deactivated.</p>
 743
 744 <p>Underscores in v-strings without a leading &#39;v&#39; are now parsed correctly.</p>
 745
 746 <p>Several comments have been updated.</p>
 747
 748 <p>31 May 2021, ef44e70.</p>
 749
 750 </dd>
 751 <dt id="Fix-parsing-error-at-operator-following-a-comma"><b>Fix parsing error at operator following a comma</b></dt>
 752 <dd>
 753
 754 <p>The following lines are syntactically correct but some were producing a syntax error</p>
 755
 756 <pre><code>    print &quot;hello1\n&quot;, || print &quot;hi1\n&quot;;
 757     print &quot;hello2\n&quot;, &amp;&amp; print &quot;bye2\n&quot;;
 758     print &quot;hello3\n&quot;, or print &quot;bye3\n&quot;;
 759     print &quot;hello4\n&quot;, and print &quot;bye4\n&quot;;</code></pre>
 760
 761 <p>For example, the first line produced this message</p>
 762
 763 <pre><code>    1: print &quot;hello1\n&quot;, || print &quot;hi1\n&quot;;
 764                        - ^
 765     found || where term expected (previous token underlined)</code></pre>
 766
 767 <p>This has been fixed. This fixes case c015.</p>
 768
 769 <p>27 May 2021, b537a72.</p>
 770
 771 </dd>
 772 <dt id="Added-optional-o-in-octal-number-definitions"><b>Added optional o in octal number definitions</b></dt>
 773 <dd>
 774
 775 <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>
 776
 777 <p>For example:</p>
 778
 779 <pre><code>    $a = 0o100;
 780     $a = 0O100;</code></pre>
 781
 782 <p>26 May 2021, 544df8c.</p>
 783
 784 </dd>
 785 <dt id="Fix-several-problems-with--lp-formatting"><b>Fix several problems with -lp formatting</b></dt>
 786 <dd>
 787
 788 <p>This update fixes several problems with -lp formatting which are all somewhat related.</p>
 789
 790 <p>ISSUE #1 (cases c002 and c004): A problem involving -lp -wn and certain qw lists</p>
 791
 792 <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>
 793
 794 <p>A few examples (all use &#39;perltidy -wn -lp&#39;):</p>
 795
 796 <pre><code>    # OLD and NEW: OK, closing qw paren is on separate line
 797     $roads-&gt;add_capacity_path( qw( CoolCity 10 ChocolateGulch 8
 798                                PecanPeak 10 BlueberryWoods 6
 799                                HotCity
 800     ) );
 801
 802     # OLD: poor; outdented text not aligned with previous text
 803     $roads-&gt;add_capacity_path( qw( CoolCity 10 ChocolateGulch 8
 804                                PecanPeak 10 BlueberryWoods 6
 805     HotCity ) );
 806
 807     # NEW:
 808     $roads-&gt;add_capacity_path( qw( CoolCity 10 ChocolateGulch 8
 809                                PecanPeak 10 BlueberryWoods 6
 810                                HotCity ) );
 811
 812     # OLD:
 813     $roads-&gt;add_capacity_path( qw( ChocolateGulch 3 StrawberryFields 0
 814     StrawberryFields ) );
 815
 816     # NEW:
 817     $roads-&gt;add_capacity_path( qw( ChocolateGulch 3 StrawberryFields 0
 818                                StrawberryFields ) );
 819
 820     # OLD:
 821     my $mon_name = ( qw(January February March April
 822                      May June July August
 823     September October November December) )[$mon];
 824
 825     # NEW
 826     my $mon_name = ( qw(January February March April
 827                      May June July August
 828                      September October November December) )[$mon];</code></pre>
 829
 830 <p>ISSUE #2 (case c007): A rare program error could be triggered with -lp -xci</p>
 831
 832 <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>
 833
 834 <pre><code>    # OLD: perltidy -lp -xci, gave an error message and extra indentation here
 835     my %specified_opts = (
 836           (
 837                           map { /^no-?(.*)$/i ? ($1 =&gt; 0) : ($_ =&gt; 1) }
 838                           map { /^--([\-_\w]+)$/ } @ARGV
 839           ),    # this comment caused an error with flags -lp -xci
 840     );
 841
 842     # NEW: perltidy -lp -xci, no error
 843     my %specified_opts = (
 844           (
 845              map { /^no-?(.*)$/i ? ( $1 =&gt; 0 ) : ( $_ =&gt; 1 ) }
 846              map { /^--([\-_\w]+)$/ } @ARGV
 847           ),    # this comment caused an error with flags -lp -xci
 848     );</code></pre>
 849
 850 <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>
 851
 852 <pre><code>    # NEW: perltidy -lp
 853     $result = runperl(
 854         switches =&gt; [ &#39;-I.&#39;, &quot;-w&quot; ],
 855         stderr   =&gt; 1,
 856         prog     =&gt; &lt;&lt;&#39;PROG&#39; );
 857     SIG
 858     PROG
 859
 860     # NEW: perltidy -lp
 861     $result = runperl(
 862                        switches =&gt; [ &#39;-I.&#39;, &quot;-w&quot; ],
 863                        stderr   =&gt; 1,
 864                        prog     =&gt; &lt;&lt;&#39;PROG&#39; );
 865     SIG
 866     PROG</code></pre>
 867
 868 <p>25 May 2021, 6947fe9.</p>
 869
 870 </dd>
 871 <dt id="Modify-welding-rules"><b>Modify welding rules</b></dt>
 872 <dd>
 873
 874 <p>This is an update to the patch 19 Apr 2021, eeeaf09. It restricts that patch to -lp formatting mode.</p>
 875
 876 <p>This fixes case b1131.</p>
 877
 878 <p>21 May 2021, a4ec4c1.</p>
 879
 880 </dd>
 881 <dt id="Fix-inconsistency-involving-counting-commas"><b>Fix inconsistency involving counting commas</b></dt>
 882 <dd>
 883
 884 <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>
 885
 886 <p>This fixes case b1130.</p>
 887
 888 <p>15 May 2021, 90cceb1.</p>
 889
 890 </dd>
 891 <dt id="Slightly-modify-line-breaks-for--lp-indentation"><b>Slightly modify line breaks for -lp indentation</b></dt>
 892 <dd>
 893
 894 <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>
 895
 896 <p>This fixes b1035.</p>
 897
 898 <p>15 May 2021, dd42648.</p>
 899
 900 </dd>
 901 <dt id="Rewrite-coding-for--bom-flag"><b>Rewrite coding for -bom flag</b></dt>
 902 <dd>
 903
 904 <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>
 905
 906 <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>
 907
 908 <pre><code>    # input:
 909     $show = $top-&gt;Entry( &#39;-width&#39; =&gt; 20,
 910                        )-&gt;pack(&#39;-side&#39; =&gt; &#39;left&#39;);
 911
 912     # OLD: perltidy -gnu -bom
 913     $show = $top-&gt;Entry(&#39;-width&#39; =&gt; 20,)-&gt;pack(&#39;-side&#39; =&gt; &#39;left&#39;);
 914
 915     # NEW: perltidy -gnu -bom
 916     $show = $top-&gt;Entry(
 917                         &#39;-width&#39; =&gt; 20,
 918                        )-&gt;pack(&#39;-side&#39; =&gt; &#39;left&#39;);</code></pre>
 919
 920 <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>
 921
 922 <pre><code>        # input
 923         $_make_phase_arg = join(&quot; &quot;,
 924                            map {CPAN::HandleConfig
 925                                  -&gt;safe_quote($_)} @{$prefs-&gt;{$phase}{args}},
 926                           );
 927
 928         # OLD: perltidy -gnu -bom
 929         $_make_phase_arg = join(&quot; &quot;,
 930                                 map { CPAN::HandleConfig-&gt;safe_quote($_) }
 931                                   @{$prefs-&gt;{$phase}{args}},
 932                                );
 933
 934         # NEW: perltidy -gnu -bom
 935         $_make_phase_arg = join(
 936             &quot; &quot;,
 937             map {
 938                 CPAN::HandleConfig
 939                   -&gt;safe_quote($_)
 940             } @{$prefs-&gt;{$phase}{args}},
 941         );</code></pre>
 942
 943 <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>
 944
 945 <pre><code>    # Starting script
 946     $lb = $t-&gt;Scrolled(&quot;Listbox&quot;, -scrollbars =&gt; &quot;osoe&quot;
 947                       )-&gt;pack(-fill =&gt; &quot;both&quot;, -expand =&gt; 1);
 948
 949     # OLD: perltidy -bom -gnu
 950     $lb = $t-&gt;Scrolled( &quot;Listbox&quot;, -scrollbars =&gt; &quot;osoe&quot; )
 951       -&gt;pack( -fill =&gt; &quot;both&quot;, -expand =&gt; 1 );
 952
 953     # NEW: perltidy -bom -gnu
 954     $lb = $t-&gt;Scrolled(
 955                        &quot;Listbox&quot;, -scrollbars =&gt; &quot;osoe&quot;
 956                       )-&gt;pack(-fill =&gt; &quot;both&quot;, -expand =&gt; 1);</code></pre>
 957
 958 <p>In the following example, a leading &#39;)-&gt;&#39; was being lost, again due to the old b977 fix:</p>
 959
 960 <pre><code>    $myDiag-&gt;Label(-text =&gt; $text,
 961                                   )-&gt;pack(-fill =&gt; &#39;x&#39;,
 962                                                   -padx =&gt; 3,
 963                                                   -pady =&gt; 3);
 964
 965     # OLD: -gnu -bom
 966     $myDiag-&gt;Label(-text =&gt; $text,)-&gt;pack(
 967                                           -fill =&gt; &#39;x&#39;,
 968                                           -padx =&gt; 3,
 969                                           -pady =&gt; 3
 970                                          );
 971
 972     # NEW -gnu -bom
 973     $myDiag-&gt;Label(
 974                    -text =&gt; $text,
 975       )-&gt;pack(
 976               -fill =&gt; &#39;x&#39;,
 977               -padx =&gt; 3,
 978               -pady =&gt; 3
 979              );</code></pre>
 980
 981 <p>This update fixes case b1120 and revises the fix for b977.</p>
 982
 983 <p>13 May 2021, d0ac5e9.</p>
 984
 985 </dd>
 986 <dt id="Adjust-tolerances-for-some-line-length-tests"><b>Adjust tolerances for some line length tests</b></dt>
 987 <dd>
 988
 989 <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>
 990
 991 <p>This fixes cases b1059 b1063 b1117.</p>
 992
 993 <p>13 May 2021, 24a11d3.</p>
 994
 995 </dd>
 996 <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>
 997 <dd>
 998
 999 <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>
1000
1001 <p>But note that if a container contains a here target but not the here text so it still gets the -lp indentation:</p>
1002
1003 <pre><code>    # perltidy -lp
1004     &amp;WH::Spell::AddSpell(
1005                           &quot;Cause Light Wounds&quot;, &quot;WFP&quot;,
1006                           &quot;CauseLightWounds&quot;,   &lt;&lt;&#39;EOH&#39;);
1007     ...
1008     EOH</code></pre>
1009
1010 <p>This fixes case b1081.</p>
1011
1012 <p>10 May 2021, 4f7a56b.</p>
1013
1014 </dd>
1015 <dt id="Fix-some-edge-welding-cases"><b>Fix some edge welding cases</b></dt>
1016 <dd>
1017
1018 <p>Some adjustments in welding coding was made to maintain stability for some unusual parameter combinations.</p>
1019
1020 <p>This fixes cases b1111 b1112.</p>
1021
1022 <p>9 May 2021, 68f619a.</p>
1023
1024 </dd>
1025 <dt id="Improve-tolerance-for-welding-qw-quotes"><b>Improve tolerance for welding qw quotes</b></dt>
1026 <dd>
1027
1028 <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>
1029
1030 <p>9 May 2021, d1de85f.</p>
1031
1032 </dd>
1033 <dt id="Revise-weld-tolerances-simplify-code-fix-welded-ci"><b>Revise weld tolerances, simplify code, fix welded ci</b></dt>
1034 <dd>
1035
1036 <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>
1037
1038 <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>
1039
1040 <pre><code>    # OLD: perltidy -wn -gnu
1041     emit_symbols([qw(
1042      ctermid
1043      get_sysinfo
1044      Perl_OS2_init
1045      ...
1046      CroakWinError
1047     )]);
1048
1049     # NEW: perltidy -wn -gnu
1050     emit_symbols([qw(
1051         ctermid
1052         get_sysinfo
1053         Perl_OS2_init
1054         ...
1055         CroakWinError
1056     )]);</code></pre>
1057
1058 <p>9 May 2021, ad8870b.</p>
1059
1060 </dd>
1061 <dt id="Correct-brace-types-mismarked-by-tokenizer-update"><b>Correct brace types mismarked by tokenizer, update</b></dt>
1062 <dd>
1063
1064 <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>
1065
1066 <p>8 May 2021, b3eaf23.</p>
1067
1068 </dd>
1069 <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>
1070 <dd>
1071
1072 <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>
1073
1074 <p>7 May 2021, e9e14e4.</p>
1075
1076 </dd>
1077 <dt id="Improve-indentation-of-welded-multiline-qw-quotes"><b>Improve indentation of welded multiline qw quotes</b></dt>
1078 <dd>
1079
1080 <p>Formatting of multiline qw lists with welding works best if the opening and closing qw tokens are on separate lines, like this:</p>
1081
1082 <pre><code>    # perltidy -wn
1083     my $mon_name = ( qw(
1084         January February March April
1085         May June July August
1086         September October November December
1087     ) )[$mon];
1088
1089     # perltidy -wn -lp
1090     my $mon_name = ( qw(
1091                      January February March April
1092                      May June July August
1093                      September October November December
1094     ) )[$mon];</code></pre>
1095
1096 <p>Otherwise formatting can be poor, particularly if the last line has text and a closing container.</p>
1097
1098 <pre><code>    # OLD: perltidy -wn
1099     my $mon_name = ( qw(January February March April
1100         May June July August
1101     September October November December) )[$mon];</code></pre>
1102
1103 <p>Note that perltidy does not change the line breaks within multiline quotes, so they must be changed by hand if desired.</p>
1104
1105 <p>This update indents the last line of a multiline quote which contains both text and the closing token, such as:</p>
1106
1107 <pre><code>    # NEW: perltidy -wn
1108     my $mon_name = ( qw(January February March April
1109         May June July August
1110         September October November December) )[$mon];</code></pre>
1111
1112 <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>
1113
1114 <pre><code>    $ OLD and NEW: perltidy -wn -lp
1115     my $mon_name = ( qw(January February March April
1116                      May June July August
1117     September October November December) )[$mon];</code></pre>
1118
1119 <p>This is difficult to fix. The best solution is to place the closing qw qw containers on a separate line.</p>
1120
1121 <p>This fix is for case c002.</p>
1122
1123 <p>6 May 2021, 176f8a7.</p>
1124
1125 </dd>
1126 <dt id="Test-length-of-closing-multiline-qw-quote-before-welding"><b>Test length of closing multiline qw quote before welding</b></dt>
1127 <dd>
1128
1129 <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>
1130
1131 <p>5 May 2021, b72ad24.</p>
1132
1133 </dd>
1134 <dt id="Update-welding-rule-to-avoid-blinking-states"><b>Update welding rule to avoid blinking states</b></dt>
1135 <dd>
1136
1137 <p>Random testing with unusual parameter combinations produced some unstable welds. For example case b1106 has these parameters</p>
1138
1139 <pre><code>    --noadd-whitespace
1140     --continuation-indentation=6
1141     --delete-old-whitespace
1142     --line-up-parentheses
1143     --maximum-line-length=36
1144     --variable-maximum-line-length
1145     --weld-nested-containers</code></pre>
1146
1147 <p>and was switching between these two states:</p>
1148
1149 <pre><code>            return map{
1150                 ($_,[$self-&gt;$_(@_[1..$#_])])
1151             }@every;
1152
1153             return map { (
1154                 $_, [ $self-&gt;$_( @_[ 1 .. $#_ ] ) ]
1155             ) } @every;</code></pre>
1156
1157 <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>
1158
1159 <p>This update fixes cases b1082 b1102 b1106 b1115.</p>
1160
1161 <p>4 May 2021, 07efa9d.</p>
1162
1163 </dd>
1164 <dt id="Fix-problem-of-conflict-of--otr-and--lp"><b>Fix problem of conflict of -otr and -lp</b></dt>
1165 <dd>
1166
1167 <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>
1168
1169 <p>This fixes cases b964 b1040 b1062 b1083 b1089.</p>
1170
1171 <p>4 May 2021, 24a0d32.</p>
1172
1173 </dd>
1174 <dt id="Add-option--pvtc-3-requested-in-rt136417"><b>Add option -pvtc=3, requested in rt136417</b></dt>
1175 <dd>
1176
1177 <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>
1178
1179 <p>3 May 2021, 93063a7.</p>
1180
1181 </dd>
1182 <dt id="Fix-vertical-alignment-issue-in-rt136416"><b>Fix vertical alignment issue in rt136416</b></dt>
1183 <dd>
1184
1185 <p>This update fixes a problem with unwanted vertical alignment rasied in rt#136416. The example is</p>
1186
1187 <pre><code>    use File::Spec::Functions &#39;catfile&#39;, &#39;catdir&#39;;
1188     use Mojo::Base &#39;Mojolicious&#39;,        &#39;-signatures&#39;;</code></pre>
1189
1190 <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>
1191
1192 <p>3 May 2021, 048126c.</p>
1193
1194 </dd>
1195 <dt id="Fix-some-rare-issues-with-the--lp-option"><b>Fix some rare issues with the -lp option</b></dt>
1196 <dd>
1197
1198 <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>
1199
1200 <p>2 May 2021, a8d1c8b.</p>
1201
1202 </dd>
1203 <dt id="Correct-brace-types-mismarked-by-tokenizer"><b>Correct brace types mismarked by tokenizer</b></dt>
1204 <dd>
1205
1206 <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>
1207
1208 <p>This fixes cases b1125 b1126 b1127.</p>
1209
1210 <p>2 May 2021, dac97cb.</p>
1211
1212 </dd>
1213 <dt id="Avoid-instability-of-combination--bbx-2--lp-and--xci"><b>Avoid instability of combination -bbx=2 -lp and -xci</b></dt>
1214 <dd>
1215
1216 <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>
1217
1218 <p>This fixes cases b1090 b1095 b1101 b1116 b1118 b1121 b1122 b1099</p>
1219
1220 <p>1 May 2021, 4cb81ba.</p>
1221
1222 </dd>
1223 <dt id="Restrict-use-of-flag--cab-3-to-simple-structures"><b>Restrict use of flag -cab=3 to simple structures</b></dt>
1224 <dd>
1225
1226 <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>
1227
1228 <p>For example, using these parameters for case b1113</p>
1229
1230 <pre><code>    --noadd-whitespace
1231     --break-before-hash-brace-and-indent=2
1232     --break-before-hash-brace=1
1233     --comma-arrow-breakpoints=3
1234     --continuation-indentation=9
1235     --maximum-line-length=76
1236     --variable-maximum-line-length</code></pre>
1237
1238 <p>formatting of the following snippet was unstable:</p>
1239
1240 <pre><code>    $STYLESHEET{&#39;html-light&#39;}={
1241         &#39;tags&#39;=&gt;{
1242             &#39;predefined identifier&#39;=&gt;
1243                      {
1244                 &#39;start&#39;=&gt;&#39;&lt;font color=&quot;#2040a0&quot;&gt;&lt;strong&gt;&#39;,
1245                 &#39;stop&#39;=&gt;&#39;&lt;/strong&gt;&lt;/font&gt;&#39;
1246                      },
1247         }
1248     };</code></pre>
1249
1250 <p>This update fixes cases b1096 b1113.</p>
1251
1252 <p>29 Apr 2021, 32a1830.</p>
1253
1254 </dd>
1255 <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>
1256 <dd>
1257
1258 <p>The wording regarding when -lp reverts to the default indentation scheme has been revised to include side comment as follows:</p>
1259
1260 <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>
1261
1262 <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>
1263
1264 <pre><code>    # perltidy -lp
1265     $gif-&gt;arc(
1266                50, 50,     # Center x, y.
1267                30, 30,     # Width, Height.
1268                0,  360,    # Start Angle, End Angle.
1269                $red
1270     );</code></pre>
1271
1272 <p>But if a list is more than one level deep then the default indentation is used.</p>
1273
1274 <p>28 Apr 2021, 49977b8.</p>
1275
1276 </dd>
1277 <dt id="Fix-line-break-rules-for-uncontained-commas-cleanups"><b>Fix line break rules for uncontained commas + cleanups</b></dt>
1278 <dd>
1279
1280 <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>
1281
1282 <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>
1283
1284 <p>26 Apr 2021, d014c2a.</p>
1285
1286 </dd>
1287 <dt id="Fix-problem-with--wn-and--wc-n"><b>Fix problem with -wn and -wc=n</b></dt>
1288 <dd>
1289
1290 <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>
1291
1292 <p>This fixes cases: b1098 b1107 25 Apr 2021, 92babdf.</p>
1293
1294 </dd>
1295 <dt id="Adjust-line-break-rules-for-uncontained-commas"><b>Adjust line break rules for uncontained commas</b></dt>
1296 <dd>
1297
1298 <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>
1299
1300 <p>20 Apr 2021, 344519e.</p>
1301
1302 </dd>
1303 <dt id="Fix-a-bad-line-break-choice-at-a-slash"><b>Fix a bad line break choice at a slash</b></dt>
1304 <dd>
1305
1306 <p>Random testing produced case c001 in which the following snipppet</p>
1307
1308 <pre><code>   ok $mi/(@mtime-1) &gt;= 0.75 &amp;&amp; $ai/(@atime-1) &gt;= 0.75 &amp;&amp;
1309              $ss/(@mtime+@atime) &gt;= 0.2;</code></pre>
1310
1311 <p>when processed with these parameters</p>
1312
1313 <pre><code>    --maximum-line-length=20
1314     --nowant-right-space=&#39; / &#39;
1315     --want-break-before=&#39;* /&#39;</code></pre>
1316
1317 <p>produced the following result</p>
1318
1319 <pre><code>    ok $mi
1320       /( @mtime - 1 ) &gt;=
1321       0.75
1322       &amp;&amp; $ai
1323       /( @atime - 1 )
1324       &gt;= 0.75
1325       &amp;&amp; $ss
1326       /( @mtime +
1327           @atime ) &gt;=
1328       0.2;</code></pre>
1329
1330 <p>using &#39;perl -cw&#39; on this snippet gives a syntax error</p>
1331
1332 <pre><code>    syntax error at /tmp/issues.t line 5, near &quot;/( &quot;
1333         (Might be a runaway multi-line // string starting on line 2)</code></pre>
1334
1335 <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>
1336
1337 <p>20 Apr 2021, 4fbc69a.</p>
1338
1339 </dd>
1340 <dt id="Fix-rare-problem-with--lp--wn"><b>Fix rare problem with -lp -wn</b></dt>
1341 <dd>
1342
1343 <p>Random testing produced case b1114 which gave unstable formatting with these parameters</p>
1344
1345 <pre><code>    --noadd-whitespace
1346     --indent-columns=8
1347     --line-up-parentheses
1348     --maximum-line-length=25
1349     --weld-nested-containers</code></pre>
1350
1351 <p>and this snippet</p>
1352
1353 <pre><code>    is(length(pack(&quot;j&quot;, 0)),
1354         $Config{ivsize});</code></pre>
1355
1356 <p>Fixed 19 Apr 2021, eeeaf09.</p>
1357
1358 </dd>
1359 <dt id="Fix-issue-git-63"><b>Fix issue git#63</b></dt>
1360 <dd>
1361
1362 <p>The following lines produced an error message due to the side comment</p>
1363
1364 <pre><code>    my $fragment = $parser-&gt;    #parse_html_string
1365       parse_balanced_chunk($I);</code></pre>
1366
1367 <p>Fixed 18 Apr 2021, c2030cf.</p>
1368
1369 </dd>
1370 <dt id="Avoid-welding-at-sort-map-grep-paren-calls"><b>Avoid welding at sort/map/grep paren calls</b></dt>
1371 <dd>
1372
1373 <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>
1374
1375 <p>This update fixes cases b1077 b1092 b1093 b1094 b1104 b1105 b1108.</p>
1376
1377 <p>17 Apr 2021, d679b48.</p>
1378
1379 </dd>
1380 <dt id="Fix-issue-git-62"><b>Fix issue git#62</b></dt>
1381 <dd>
1382
1383 <p>This fixes issue git #62. A similar issue for the % operator was fixed. 17 Apr 2021, f80d677.</p>
1384
1385 </dd>
1386 <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>
1387 <dd>
1388
1389 <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>
1390
1391 <p>15 Apr 2021, 21ef53b.</p>
1392
1393 </dd>
1394 <dt id="Fix-rare-line-break-problem"><b>Fix rare line break problem</b></dt>
1395 <dd>
1396
1397 <p>Random testing produced case b1097 with this parameter set</p>
1398
1399 <pre><code>    --brace-vertical-tightness-closing=1
1400     --continuation-indentation=8
1401     --indent-columns=10
1402     --maximum-line-length=36</code></pre>
1403
1404 <p>and either this output</p>
1405
1406 <pre><code>          my (@files) = @{
1407                     $args{-files} };</code></pre>
1408
1409 <p>or this output</p>
1410
1411 <pre><code>          my (@files) =
1412                   @{ $args{-files}
1413                   };</code></pre>
1414
1415 <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>
1416
1417 <p>15 Apr 2021, 9f15b9d.</p>
1418
1419 </dd>
1420 <dt id="Fix-problem-parsing-anonymous-subs-with-attribute-lists"><b>Fix problem parsing anonymous subs with attribute lists</b></dt>
1421 <dd>
1422
1423 <p>Random testing produced case b994 with unstable formatting:</p>
1424
1425 <pre><code>    do
1426     sub :
1427     lvalue
1428     {
1429     return;
1430     }</code></pre>
1431
1432 <p>when run with parameters:</p>
1433
1434 <pre><code>    --continuation-indentation=0
1435     --ignore-old-breakpoints
1436     --maximum-line-length=7
1437     --opening-anonymous-sub-brace-on-new-line</code></pre>
1438
1439 <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>
1440
1441 <p>15 Apr 2021, 84c1123.</p>
1442
1443 </dd>
1444 <dt id="Correct-brace-types-mismarked-by-tokenizer1"><b>Correct brace types mismarked by tokenizer</b></dt>
1445 <dd>
1446
1447 <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>
1448
1449 <p>11 Apr 2021, 7d23bf4.</p>
1450
1451 </dd>
1452 <dt id="Unify-coding-for-welded-quotes-and-other-welded-containers"><b>Unify coding for welded quotes and other welded containers</b></dt>
1453 <dd>
1454
1455 <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>
1456
1457 <p>This update fixes cases b1066 b1067 b1071 b1079 b1080.</p>
1458
1459 <p>10 Apr 2021, 5d73dd5.</p>
1460
1461 </dd>
1462 <dt id="Slight-change-in-weld-length-calculation"><b>Slight change in weld length calculation</b></dt>
1463 <dd>
1464
1465 <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>
1466
1467 <p>9 Apr 2021, a25cfaa.</p>
1468
1469 </dd>
1470 <dt id="Improve-treatment-of--vmll-with--wn"><b>Improve treatment of -vmll with -wn</b></dt>
1471 <dd>
1472
1473 <p>Random testing showed a weakness in the treatment of the -vmll flag in combination with the -wn flag. This has been fixed.</p>
1474
1475 <p>This fixes cases b866 b1074 b1075 b1084 b1086 b1087 b1088</p>
1476
1477 <p>8 Apr 2021, a6effa3.</p>
1478
1479 </dd>
1480 <dt id="Merge-weld-rule-6-into-rule-3"><b>Merge weld rule 6 into rule 3</b></dt>
1481 <dd>
1482
1483 <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>
1484
1485 <p>8 Apr 2021, f28ab55.</p>
1486
1487 </dd>
1488 <dt id="Moved-logic-of-previous-update-to-the-FileWriter-module"><b>Moved logic of previous update to the FileWriter module</b></dt>
1489 <dd>
1490
1491 <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>
1492
1493 <p>6 Apr 2021, 756e930.</p>
1494
1495 </dd>
1496 <dt id="Fix-problem-with-excess-blank-line-generation-with--blao"><b>Fix problem with excess blank line generation with -blao</b></dt>
1497 <dd>
1498
1499 <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>
1500
1501 <pre><code>    sub stop {
1502
1503         1;
1504     }</code></pre>
1505
1506 <p>and the following parameters</p>
1507
1508 <pre><code>    --blank-lines-after-opening-block=2
1509     --maximum-consecutive-blank-lines=10
1510     --maximum-line-length=15</code></pre>
1511
1512 <p>When run, blank lines keep getting generated until the maximum is reached. This has been fixed.</p>
1513
1514 <p>6 Apr 2021, 9216298.</p>
1515
1516 </dd>
1517 <dt id="Fix-edge-case-involving--wn-and--lp-or--bbao"><b>Fix edge case involving -wn and -lp or -bbao</b></dt>
1518 <dd>
1519
1520 <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>
1521
1522 <p>5 Apr 2021.</p>
1523
1524 </dd>
1525 <dt id="Modify-a-condition-for-applying--bbx-2"><b>Modify a condition for applying -bbx=2</b></dt>
1526 <dd>
1527
1528 <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>
1529
1530 <p>This update fixes cases b1068 b1069 b1070 b1072 b1073 b1076.</p>
1531
1532 <p>5 Apr 2021, 16c4591.</p>
1533
1534 </dd>
1535 <dt id="Improve-previous--wn-update"><b>Improve previous -wn update</b></dt>
1536 <dd>
1537
1538 <p>The previous update produced some problems in testing which are corrected with this update.</p>
1539
1540 <p>5 Apr 2021, ffef089.</p>
1541
1542 </dd>
1543 <dt id="Fix-rare-convergence-problem-with--wn"><b>Fix rare convergence problem with -wn</b></dt>
1544 <dd>
1545
1546 <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>
1547
1548 <p>This fixes cases b1041 b1055.</p>
1549
1550 <p>2 Apr 2021, a8b6259.</p>
1551
1552 </dd>
1553 <dt id="Avoid-conflict-of--bli-and--xci"><b>Avoid conflict of -bli and -xci</b></dt>
1554 <dd>
1555
1556 <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>
1557
1558 <p>This fixes case b1065.</p>
1559
1560 <p>2 Apr 2021, d20ea80.</p>
1561
1562 </dd>
1563 </dl>
1564
1565 <h1 id="Issues-fixed-after-release-20210111">Issues fixed after release 20210111</h1>
1566
1567 <dl>
1568
1569 <dt id="Avoid-conflict-of--bbp-2-and--xci"><b>Avoid conflict of -bbp=2 and -xci</b></dt>
1570 <dd>
1571
1572 <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>
1573
1574 <p>This fixes cases b1033 b1036 b1037 b1038 b1042 b1043 b1044 b1045 b1046 b1047 b1051 b1052 b1061.</p>
1575
1576 <p>30 Mar 2021, 2b05051.</p>
1577
1578 </dd>
1579 <dt id="Fix-rule-for-welding-with-barewords"><b>Fix rule for welding with barewords</b></dt>
1580 <dd>
1581
1582 <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>
1583
1584 <p>This fixes cases b1057 b1064.</p>
1585
1586 <p>29 Mar 2021, d677082.</p>
1587
1588 </dd>
1589 <dt id="Fix-conflict-between--wba-and--opr"><b>Fix conflict between -wba=&#39;||&#39; and -opr</b></dt>
1590 <dd>
1591
1592 <p>Random testing produced a problem with convergence due to a conflict between two parameters for the following code</p>
1593
1594 <pre><code>    my $lxy =
1595       ( @$cx - @$cy ) ||
1596       (
1597         length ( int ( $cx-&gt;[-1] ) ) -
1598         length ( int ( $cy-&gt;[-1] ) ) );</code></pre>
1599
1600 <p>when using these parameters</p>
1601
1602 <pre><code>    --break-after-all-operators
1603     --maximum-line-length=61
1604     --opening-paren-right</code></pre>
1605
1606 <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>
1607
1608 <p>29 Mar 2021, 6921a7d.</p>
1609
1610 </dd>
1611 <dt id="Follow-user-requests-better-to-break-before-operators"><b>Follow user requests better to break before operators</b></dt>
1612 <dd>
1613
1614 <p>Random testing produced some cases in which user requests to break before selected operators were not being followed. For example</p>
1615
1616 <pre><code>    # OLD: perltidy -wbb=&#39;.=&#39;
1617     $value .=
1618       ( grep /\s/, ( $value, $next ) )
1619       ? &quot; $next&quot;
1620       : $next;
1621
1622     # FIXED: perltidy -wbb=&#39;.=&#39;
1623     $value
1624       .= ( grep /\s/, ( $value, $next ) )
1625       ? &quot; $next&quot;
1626       : $next;</code></pre>
1627
1628 <p>This fixes case b1054.</p>
1629
1630 <p>28 Mar 2021, 94f0877.</p>
1631
1632 </dd>
1633 <dt id="Fix-problems-with-combinations-of--iob--lp"><b>Fix problems with combinations of -iob -lp</b></dt>
1634 <dd>
1635
1636 <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>
1637
1638 <p>This update fixes these old cases: b1021 b1023</p>
1639
1640 <p>and these new cases: b1034 b1048 b1049 b1050 b1056 b1058</p>
1641
1642 <p>27 Mar 2021, cc94623.</p>
1643
1644 </dd>
1645 <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>
1646 <dd>
1647
1648 <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>
1649
1650 <p>Updated 25 Mar 2021, bfc00fp.</p>
1651
1652 </dd>
1653 <dt id="Fix-error-message-for-multiple-conflicting-specifications-in--wnxl"><b>Fix error message for multiple conflicting specifications in -wnxl</b></dt>
1654 <dd>
1655
1656 <p>There was an error in the coding for an error message which checks for conflicting requests in the -wnxl parameter.</p>
1657
1658 <p>Fixed 21 Mar 2021, 2ef97a2.</p>
1659
1660 </dd>
1661 <dt id="Fix-issue-git-57-Warn_count-was-not-initialized"><b>Fix issue git #57, Warn_count was not initialized</b></dt>
1662 <dd>
1663
1664 <p>This update fixes issue git #57, in which a warning flag was not getting zeroed on each new call to perltidy.</p>
1665
1666 <p>19 Mar 2021, b6d296a.</p>
1667
1668 </dd>
1669 <dt id="Fix-rare-problem-with-combination--lp--wn--naws"><b>Fix rare problem with combination -lp -wn -naws</b></dt>
1670 <dd>
1671
1672 <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>
1673
1674 <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>
1675
1676 <p>18 Mar 2021, 6200034.</p>
1677
1678 </dd>
1679 <dt id="Fix-definition-of-list-within-list-for--bbx-flags"><b>Fix definition of list within list for -bbx flags</b></dt>
1680 <dd>
1681
1682 <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>
1683
1684 <p>17 Mar 2021, 7f5da0a.</p>
1685
1686 </dd>
1687 <dt id="Fix-problem-with--xci-and-long-tokens"><b>Fix problem with -xci and long tokens</b></dt>
1688 <dd>
1689
1690 <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>
1691
1692 <p>16 Mar 2021, 7a6be43.</p>
1693
1694 </dd>
1695 <dt id="Fix-error-in-parsing-use-statement-curly-brace"><b>Fix error in parsing use statement curly brace</b></dt>
1696 <dd>
1697
1698 <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>
1699
1700 <p>This fixes cases b1022 b1025 b1026 b1027 b1028 b1029 b1030</p>
1701
1702 <p>16 Mar 2021, 6371be2.</p>
1703
1704 </dd>
1705 <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>
1706 <dd>
1707
1708 <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>
1709
1710 <p>The following cases are fixed: b1019 b1020 b1021 b1023</p>
1711
1712 <p>13 Mar 2021, 71adc77.</p>
1713
1714 </dd>
1715 <dt id="Simplify-sub-weld_nested_containers"><b>Simplify sub weld_nested_containers</b></dt>
1716 <dd>
1717
1718 <p>This update consolidates a number of specialized rules for welding into fewer, simpler rules which accomplish the same effect.</p>
1719
1720 <p>These cases are fixed with this update: b186 b520 b872 b937 b996 b997 b1002 b1003 b1004 b1005 b1006 b1013 b1014</p>
1721
1722 <p>There are no current open issues with the weld logic.</p>
1723
1724 <p>10 Mar 2021, cf3ed23.</p>
1725
1726 </dd>
1727 <dt id="Adjust-line-length-tolerance-for-welding"><b>Adjust line length tolerance for welding</b></dt>
1728 <dd>
1729
1730 <p>A minor tolerance adjustment was needed to fix some edge welding cases.</p>
1731
1732 <p>This fixes cases b995 b998 b1000 b1001 b1007 b1008 b1009 b1010 b1011 b1012 b1016 b1017 b1018</p>
1733
1734 <p>7 Mar 2021, b9166ca.</p>
1735
1736 </dd>
1737 <dt id="Fix-problem-with--vtc-n-and-outdented-long-lines"><b>Fix problem with -vtc=n and outdented long lines</b></dt>
1738 <dd>
1739
1740 <p>Random testing produced an issue with -vtc=1 and an outdented long line. The parameters for b999 are</p>
1741
1742 <pre><code>    --maximum-line-length=75
1743     --paren-vertical-tightness-closing=1</code></pre>
1744
1745 <p>File &#39;b999.in&#39; state 1 is</p>
1746
1747 <pre><code>                while ( $line =~
1748     s/^([^\t]*)(\t+)/$1.(&quot; &quot; x ((length($2)&lt;&lt;3)-(length($1)&amp;7)))/e
1749                   )</code></pre>
1750
1751 <p>and state 2 is</p>
1752
1753 <pre><code>                while ( $line =~
1754     s/^([^\t]*)(\t+)/$1.(&quot; &quot; x ((length($2)&lt;&lt;3)-(length($1)&amp;7)))/e)</code></pre>
1755
1756 <p>The problem was fixed by turning off caching for outdented long lines. This fixes case b999.</p>
1757
1758 <p>7 Mar 2021, 3da7e41.</p>
1759
1760 </dd>
1761 <dt id="Fix-problem-with-combination--lp-and--wbb"><b>Fix problem with combination -lp and -wbb=&#39;=&#39;</b></dt>
1762 <dd>
1763
1764 <p>Random testing produced case b932 in which the combination -lp and -wbb=&#39;=&#39; was not stable.</p>
1765
1766 <p>File &#39;b932.par&#39; is:</p>
1767
1768 <pre><code>    --line-up-parentheses
1769     --maximum-line-length=51
1770     --want-break-before=&#39;=&#39;</code></pre>
1771
1772 <p>File &#39;b932.in&#39; in the desired state is:</p>
1773
1774 <pre><code>    my @parts
1775       = decompose( &#39;(\s+|/|\!|=)&#39;,
1776                    $line, undef, 1, undef, &#39;[&quot;\&#39;]&#39; );</code></pre>
1777
1778 <p>The alternate state is</p>
1779
1780 <pre><code>    my @parts = decompose( &#39;(\s+|/|\!|=)&#39;,
1781                      $line, undef, 1, undef, &#39;[&quot;\&#39;]&#39; );</code></pre>
1782
1783 <p>The problem was that the -lp code which set a line break at the equals did not check the -wba flag setting.</p>
1784
1785 <p>This update fixes case b932.</p>
1786
1787 <p>7 Mar 2021, 63129c3.</p>
1788
1789 </dd>
1790 <dt id="Fix-edge-formatting-cases-with-parameter--bbx-2"><b>Fix edge formatting cases with parameter -bbx=2</b></dt>
1791 <dd>
1792
1793 <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>
1794
1795 <p>6 Mar 2021, 360d669.</p>
1796
1797 </dd>
1798 <dt id="Add-flag--fpva---function-paren-vertical-alignment"><b>Add flag -fpva, --function-paren-vertical-alignment</b></dt>
1799 <dd>
1800
1801 <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>
1802
1803 <p>5 Mar 2021, 312be4c.</p>
1804
1805 </dd>
1806 <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>
1807 <dd>
1808
1809 <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>
1810
1811 <pre><code>    # OLD and NEW, default without -sfp:
1812     log_something_with_long_function( &#39;This is a log message.&#39;, 2 );
1813     Coro::AnyEvent::sleep( 3, 4 );
1814
1815     # OLD: perltidy -sfp
1816     log_something_with_long_function ( &#39;This is a log message.&#39;, 2 );
1817     Coro::AnyEvent::sleep            ( 3, 4 );
1818
1819     # NEW: perltidy -sfp
1820     log_something_with_long_function ( &#39;This is a log message.&#39;, 2 );
1821     Coro::AnyEvent::sleep ( 3, 4 );</code></pre>
1822
1823 <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>
1824
1825 <p>5 Mar 2021, 00431bf.</p>
1826
1827 </dd>
1828 <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>
1829 <dd>
1830
1831 <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>
1832
1833 <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>
1834
1835 <p>4 Mar 2021, 872d4b4.</p>
1836
1837 </dd>
1838 <dt id="Fix-several-minor-weld-issues"><b>Fix several minor weld issues</b></dt>
1839 <dd>
1840
1841 <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>
1842
1843 <p>This fixes cases b109 b110 b520 b756 b901 b937 b965 b982 b988 b991 b992 b993</p>
1844
1845 <p>3 Mar 2021, cfef087.</p>
1846
1847 </dd>
1848 <dt id="Update-tokenizer-recognition-of-indirect-object"><b>Update tokenizer recognition of indirect object</b></dt>
1849 <dd>
1850
1851 <p>This is the parameter file b990.pro: --noadd-whitespace --continuation-indentation=0 --maximum-line-length=7 --space-terminal-semicolon</p>
1852
1853 <p>Applying perltidy -pro=b990.pro to the following snippet gave two states</p>
1854
1855 <pre><code>    # State 1
1856     print
1857     H;
1858
1859     # State 2
1860     print H
1861     ;</code></pre>
1862
1863 <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>
1864
1865 <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>
1866
1867 <p>This fixes case b990. 1 Mar 2021, 49cd66f.</p>
1868
1869 </dd>
1870 <dt id="Do-not-start-a-batch-with-a-blank-token"><b>Do not start a batch with a blank token</b></dt>
1871 <dd>
1872
1873 <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>
1874
1875 <pre><code>        # this is file &#39;b984.pro&#39;
1876         --block-brace-vertical-tightness=2
1877         --indent-columns=10
1878         --maximum-line-length=27
1879         --outdent-keywords
1880         --variable-maximum-line-length
1881
1882           # OLD: perltidy -pro=b984.pro
1883           unless (
1884                     exists $self-&gt;{
1885                               &#39;accession_number&#39;} )
1886           {         return &quot;unknown&quot;;
1887           }
1888
1889           # NEW: perltidy -pro=b984.pro
1890           unless (
1891                     exists $self-&gt;{
1892                               &#39;accession_number&#39;} )
1893           {       return &quot;unknown&quot;;
1894           }</code></pre>
1895
1896 <p>Both look OK, but the OLD version did not outdent the keyword &#39;return&#39; as requested with the -okw flag.</p>
1897
1898 <p>This update fixes cases b149 b888 b984 b985 b986 b987.</p>
1899
1900 <p>28 Feb 2021, 8aaf599.</p>
1901
1902 </dd>
1903 <dt id="Avoid-double-spaces-in--csc-text-output"><b>Avoid double spaces in -csc text output</b></dt>
1904 <dd>
1905
1906 <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>
1907
1908 <p>For example</p>
1909
1910 <pre><code>    while (
1911         &lt;&gt;;
1912       )
1913     {
1914        ...
1915     } ## end while ( &lt;&gt;; )</code></pre>
1916
1917 <p>Previously, the last line had an extra space after the &#39;;&#39;</p>
1918
1919 <pre><code>    } ## end while ( &lt;&gt;;  )</code></pre>
1920
1921 <p>Another example</p>
1922
1923 <pre><code>    while (
1924         do {
1925             { package DB; @a = caller( $i++ ) }
1926         }
1927       )
1928     {
1929       ...
1930     } ## end while ( do { { package DB...}})</code></pre>
1931
1932 <p>Previously the last line had an extra space between the opening braces:</p>
1933
1934 <pre><code>    } ## end while ( do {  { package DB...}})</code></pre>
1935
1936 <p>27 Feb 2021, b22e891.</p>
1937
1938 </dd>
1939 <dt id="Remove-control-of-debug-flag--fll"><b>Remove control of debug flag -fll</b></dt>
1940 <dd>
1941
1942 <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>
1943
1944 <p>27 Feb 2021, 9155b3d.</p>
1945
1946 </dd>
1947 <dt id="Restrict-previous-update-to-just--vmll"><b>Restrict previous update to just -vmll</b></dt>
1948 <dd>
1949
1950 <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>
1951
1952 <pre><code>  # perltidy -gnu
1953   ok( &quot;got to the end without dying (note without DEBUGGING passing this test means nothing)&quot;
1954     );</code></pre>
1955
1956 <p>26 Feb 2021, 2b88464.</p>
1957
1958 </dd>
1959 <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>
1960 <dd>
1961
1962 <p>This fixes case b965. The -vmll flag can produce gaps in lines which need to be included in weld line length estimates.</p>
1963
1964 <p>26 Feb 2021, a643cf2.</p>
1965
1966 </dd>
1967 <dt id="Update-rule-for-spacing-paren-after-constant-function"><b>Update rule for spacing paren after constant function</b></dt>
1968 <dd>
1969
1970 <p>Random testing produced an unstable state for the following snippet (case b934)</p>
1971
1972 <pre><code>        sub pi();
1973         if (
1974             $t &gt;
1975             pi( )
1976               )</code></pre>
1977
1978 <p>when run with these parameters:</p>
1979
1980 <pre><code>  --continuation-indentation=6
1981   --maximum-line-length=17
1982   --paren-vertical-tightness-closing=2</code></pre>
1983
1984 <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>
1985
1986 <p>This fixes case b934, 12bfdfe.</p>
1987
1988 <p>26 Feb 2021.</p>
1989
1990 </dd>
1991 <dt id="Improve-line-length-test-for-the--vtc-2-option"><b>Improve line length test for the -vtc=2 option</b></dt>
1992 <dd>
1993
1994 <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>
1995
1996 <p>This fixes cases b656 b862 b971 b972.</p>
1997
1998 <p>26 Feb 2021, 80107e0.</p>
1999
2000 </dd>
2001 <dt id="Improve-one-line-block-length-tests"><b>Improve one-line block length tests</b></dt>
2002 <dd>
2003
2004 <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>
2005
2006 <p>This fixes cases b562 b563 b574 b777 b778 b924 b936 b975 b976 b983.</p>
2007
2008 <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>
2009
2010 <p>25 Feb 2021, 92bec8d.</p>
2011
2012 </dd>
2013 <dt id="Add-tolerance-to-one-line-block-length-tests"><b>Add tolerance to one-line block length tests</b></dt>
2014 <dd>
2015
2016 <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>
2017
2018 <p>This fixes cases b069 b070 b077 b078.</p>
2019
2020 <p>21 Feb 2021, 0b97b94.</p>
2021
2022 </dd>
2023 <dt id="Restrict--bom-at-cuddled-method-calls"><b>Restrict -bom at cuddled method calls</b></dt>
2024 <dd>
2025
2026 <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>
2027
2028 <p>This fixes case b977.</p>
2029
2030 <p>21 Feb 2021, 28114e9.</p>
2031
2032 </dd>
2033 <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>
2034 <dd>
2035
2036 <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>
2037
2038 <p>These cases are fixed with this update: b966 b973</p>
2039
2040 <p>20 Feb 2021.</p>
2041
2042 </dd>
2043 <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>
2044 <dd>
2045
2046 <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>
2047
2048 <p>These cases are fixed with this update: b707 b770 b912 b920 b930 b933 b939 b940 b941 b942 b978 b974 b979 b980 b981</p>
2049
2050 <p>20 Feb 2021, c16c5ee.</p>
2051
2052 </dd>
2053 <dt id="Modify-length-tolerance-for-welding-to-qw-lists"><b>Modify length tolerance for welding to qw lists</b></dt>
2054 <dd>
2055
2056 <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>
2057
2058 <p>This fixes cases b654 b655 b943 b944 b967 b968 b969 b970.</p>
2059
2060 <p>19 Feb 2021, 0baafc8.</p>
2061
2062 </dd>
2063 <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>
2064 <dd>
2065
2066 <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>
2067
2068 </dd>
2069 <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>
2070 <dd>
2071
2072 <p>This update fixes cases b899 b935. 17 Feb 2021, b955a7c.</p>
2073
2074 </dd>
2075 <dt id="Do-not-weld-to-a-hash-brace"><b>Do not weld to a hash brace</b></dt>
2076 <dd>
2077
2078 <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>
2079
2080 <p>This will not change much existing code. This update fixes cases b751 b779.</p>
2081
2082 <p>16 Feb 2021, eb2f4e7.</p>
2083
2084 </dd>
2085 <dt id="Avoid-line-breaks-after-token-type-G"><b>Avoid line breaks after token type &#39;G&#39;</b></dt>
2086 <dd>
2087
2088 <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>
2089
2090 <p>This update fixes these cases: b900 b902 b928 b929</p>
2091
2092 <p>15 Feb 2021, f005a95.</p>
2093
2094 </dd>
2095 <dt id="Restrict-breaking-at-old-uncontained-commas"><b>Restrict breaking at old uncontained commas</b></dt>
2096 <dd>
2097
2098 <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>
2099
2100 <p>These cases are fixed with this update: b610 b757 b931</p>
2101
2102 <p>15 Feb 2021, 98b41a0.</p>
2103
2104 </dd>
2105 <dt id="Modify-line-length-test-for-the--vtc-2-option"><b>Modify line length test for the -vtc=2 option</b></dt>
2106 <dd>
2107
2108 <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>
2109
2110 <p>The following cases were re-activated after this update: b654 b655 b656 b862</p>
2111
2112 <p>15 Feb 2021, 4673fdd.</p>
2113
2114 </dd>
2115 <dt id="Use-increased-line-length-tolerance-if-ci-exceeds-i"><b>Use increased line length tolerance if ci exceeds i</b></dt>
2116 <dd>
2117
2118 <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>
2119
2120 <p>b775 b776 b826 b908 b910 b911 b923 b925 b926 b927</p>
2121
2122 <p>14 Feb 2021, 8451f2f.</p>
2123
2124 </dd>
2125 <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>
2126 <dd>
2127
2128 <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>
2129
2130 <p>13 Feb 2021, cf414fe.</p>
2131
2132 </dd>
2133 <dt id="Prevent-breaks-after-unary-plus-and-minus"><b>Prevent breaks after unary plus and minus</b></dt>
2134 <dd>
2135
2136 <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>
2137
2138 <p>13 Feb 2021, cf414fe.</p>
2139
2140 </dd>
2141 <dt id="Add-line-length-test-for-the--vtc-2-option"><b>Add line length test for the -vtc=2 option</b></dt>
2142 <dd>
2143
2144 <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>
2145
2146 <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>
2147
2148 <p>13 Feb 2021, f79a4f1.</p>
2149
2150 </dd>
2151 <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>
2152 <dd>
2153
2154 <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>
2155
2156 </dd>
2157 <dt id="Fix-problem-with-breaking-at-an-sign"><b>Fix problem with breaking at an = sign</b></dt>
2158 <dd>
2159
2160 <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>
2161
2162 <p>11 Feb 2021, f9a8543.</p>
2163
2164 </dd>
2165 <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>
2166 <dd>
2167
2168 <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>
2169
2170 <p>This fixes case b860. 11 Feb 2021, 8c13609.</p>
2171
2172 </dd>
2173 <dt id="Do-not-break-one-line-block-at-here-target"><b>Do not break one-line block at here target</b></dt>
2174 <dd>
2175
2176 <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>
2177
2178 <p>For example, the code block in the following contains a here target and was being broken into two lines:</p>
2179
2180 <pre><code>    unless ($INC{$file}) {
2181         die &lt;&lt;&quot;END_DIE&quot; }</code></pre>
2182
2183 <p>These will now be output with the blocks intact, like this</p>
2184
2185 <pre><code>    unless ($INC{$file}) { die &lt;&lt;&quot;END_DIE&quot; }</code></pre>
2186
2187 <p>This fixes case b523. 11 Feb 2021, 6d5bb74.</p>
2188
2189 </dd>
2190 <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>
2191 <dd>
2192
2193 <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>
2194
2195 <p>10 Feb 2021, 177fc3a.</p>
2196
2197 </dd>
2198 <dt id="Modify-tolerance-in-testing-for-welds"><b>Modify tolerance in testing for welds</b></dt>
2199 <dd>
2200
2201 <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>
2202
2203 <p>b746 b748 b749 b750 b752 b753 b754 b755 b756 b758 b759 b771 b772 b773 b774 b782 b783 b784 b785 b786</p>
2204
2205 <p>9 Feb 2021, a4609ac.</p>
2206
2207 </dd>
2208 <dt id="Modified-rule-for-breaking-lines-at-old-commas"><b>Modified rule for breaking lines at old commas</b></dt>
2209 <dd>
2210
2211 <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>
2212
2213 <p>b064 b065 b068 b210 b747</p>
2214
2215 <p>This change has no effect on scripts with normal parameter values. 9 Feb 2021, 5c23661.</p>
2216
2217 </dd>
2218 <dt id="Restrict-references-to-old-line-breaks"><b>Restrict references to old line breaks</b></dt>
2219 <dd>
2220
2221 <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>
2222
2223 <p>The following cases were fixed with this update:</p>
2224
2225 <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>
2226
2227 <p>8 Feb 2021, 66be455.</p>
2228
2229 </dd>
2230 <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>
2231 <dd>
2232
2233 <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>
2234
2235 <p>The following case was fixed with this update: b690.</p>
2236
2237 <p>6 Feb 2021, 3e96930.</p>
2238
2239 </dd>
2240 <dt id="add-rule-to-avoid-welding-at-some-barewords"><b>add rule to avoid welding at some barewords</b></dt>
2241 <dd>
2242
2243 <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>
2244
2245 <p>The following cases were fixed with this update: b611 b626.</p>
2246
2247 <p>6 Feb 2021, 6b1f44a</p>
2248
2249 </dd>
2250 <dt id="further-simplify--bbxi-n-implementation"><b>further simplify -bbxi=n implementation</b></dt>
2251 <dd>
2252
2253 <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>
2254
2255 </dd>
2256 <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>
2257 <dd>
2258
2259 <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>
2260
2261 <p>The following cases were fixed with this update:</p>
2262
2263 <p>b396 b397 b398 b429 b435 b457 b502 b503 b504 b505 b538 b540 b542 b617 b618 b619 b620 b621</p>
2264
2265 <p>3 Feb 2021, 67ab0ef.</p>
2266
2267 </dd>
2268 <dt id="rewrite-sub-break_before_list_opening_containers"><b>rewrite sub break_before_list_opening_containers</b></dt>
2269 <dd>
2270
2271 <p>sub break_before_list_opening_containers was rewritten to reduce the chance of producing alternating states.</p>
2272
2273 <p>The following cases were fixed with this update:</p>
2274
2275 <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>
2276
2277 <p>3 Feb 2021, 5083ab9.</p>
2278
2279 </dd>
2280 <dt id="redefine-list-to-have-at-least-one-internal-comma"><b>redefine list to have at least one internal comma</b></dt>
2281 <dd>
2282
2283 <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>
2284
2285 <p>The following cases were fixed with this update:</p>
2286
2287 <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>
2288
2289 <p>1 Feb 2021, 35078f7.</p>
2290
2291 </dd>
2292 <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>
2293 <dd>
2294
2295 <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>
2296
2297 <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>
2298
2299 <p>31 Jan 2021, 10e8bfd.</p>
2300
2301 </dd>
2302 <dt id="adjust-line-length-and-token-count-tolerances-for--wn"><b>adjust line length and token count tolerances for -wn</b></dt>
2303 <dd>
2304
2305 <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>
2306
2307 <p>b156 b157 b186 b196 b454 b520 b527 b530 b532 b533 b534 b612 b614 b625 b627</p>
2308
2309 <p>This update has no effect for realistic parameter settings.</p>
2310
2311 <p>30 Jan 2021, d359a60.</p>
2312
2313 </dd>
2314 <dt id="fix-additional-edge-blinker-cases-involving--wn"><b>fix additional edge blinker cases involving -wn</b></dt>
2315 <dd>
2316
2317 <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>
2318
2319 <p>b002 b003 b005 b006 b007 b009 b010 b014 b015 b017 b020 b111 b112 b113 b124 b126 b128 b151 b153 b439 b606</p>
2320
2321 <p>29 Jan 2021, 33f1f2b.</p>
2322
2323 </dd>
2324 <dt id="fix-additional-edge-blinker-cases-involving--wn1"><b>fix additional edge blinker cases involving -wn</b></dt>
2325 <dd>
2326
2327 <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>
2328
2329 <pre><code>    $do_not_weld ||= $excess_length_to_K-&gt;($Kinner_opening) &gt; 0;</code></pre>
2330
2331 <p>was changed to allow a 1 character margin of error:</p>
2332
2333 <pre><code>    $do_not_weld ||= $excess_length_to_K-&gt;($Kinner_opening) &gt;= 0;</code></pre>
2334
2335 <p>The following cases were fixed with this update:</p>
2336
2337 <p>b025 b075 b091 b109 b110 b152 b154 b155 b162 b168 b176 b422 b423 b424 b425 b426 b565</p>
2338
2339 <p>29 Jan 2021, 33f1f2b.</p>
2340
2341 </dd>
2342 <dt id="fix-some-edge-blinker-cases-involving--wn"><b>fix some edge blinker cases involving -wn</b></dt>
2343 <dd>
2344
2345 <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>
2346
2347 <p>b131 b134 b136 b205 b233 b238 b284 b350 b352 b358 b385 b487 b604 b605</p>
2348
2349 <p>29 Jan 2021, 33f1f2b.</p>
2350
2351 </dd>
2352 <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>
2353 <dd>
2354
2355 <p>The following cases were fixed with this update:</p>
2356
2357 <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>
2358
2359 <p>28 Jan 2021.</p>
2360
2361 </dd>
2362 <dt id="fix-problem-with-combination--cab-2-and-bbhbi-n"><b>fix problem with combination -cab=2 and bbhbi=n</b></dt>
2363 <dd>
2364
2365 <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>
2366
2367 <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>
2368
2369 <p>27 Jan 2021, 6d710de.</p>
2370
2371 </dd>
2372 <dt id="fix-problem-with--freeze-whitespace"><b>fix problem with -freeze-whitespace</b></dt>
2373 <dd>
2374
2375 <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>
2376
2377 <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>
2378
2379 <p>27 Jan 2021, 6d710de.</p>
2380
2381 </dd>
2382 <dt id="Avoid-blinking-states-associated-with--bbpi-and-similar-flags"><b>Avoid blinking states associated with -bbpi and similar flags</b></dt>
2383 <dd>
2384
2385 <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>
2386
2387 <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>
2388
2389 <p>27 Jan 2021, 96144a3.</p>
2390
2391 </dd>
2392 <dt id="Revise-coding-for-the---freeze-whitespace-option"><b>Revise coding for the --freeze-whitespace option</b></dt>
2393 <dd>
2394
2395 <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>
2396
2397 </dd>
2398 <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>
2399 <dd>
2400
2401 <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>
2402
2403 <pre><code>    # OLD (OK, outdented): perltidy -ci=4 -xci
2404     {
2405         modules =&gt; [
2406             qw(
2407                 JSON
2408             )
2409         ],
2410     }
2411
2412
2413     # OLD (indented) : perltidy -ndnl -ci=4 -xci
2414     {
2415         modules =&gt; [
2416             qw(
2417                 JSON
2418                 )
2419         ],
2420     }
2421
2422     # FIXED: perltidy -ndnl -ci=4 -xci
2423     {
2424         modules =&gt; [
2425             qw(
2426                 JSON
2427             )
2428         ],
2429     }</code></pre>
2430
2431 <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>
2432
2433 </dd>
2434 <dt id="Some-issues-with-the--lp-option"><b>Some issues with the -lp option</b></dt>
2435 <dd>
2436
2437 <p>Random testing revealed some problems involving the <b>-lp</b> option which are fixed with this update.</p>
2438
2439 <p>The problem is illustrated with the following snippet</p>
2440
2441 <pre><code>    # perltidy -lp
2442     Alien::FillOutTemplate(
2443                 &quot;$main::libdir/to-$main::desttype/$main::filetype/spec&quot;,
2444                 &quot;$workdir/$fields{NAME}-$fields{VERSION}-$fields{RELEASE}.spec&quot;,
2445                 %fields
2446     );</code></pre>
2447
2448 <p>which alternately formats to this form</p>
2449
2450 <pre><code>    # perltidy -lp
2451     Alien::FillOutTemplate(
2452                 &quot;$main::libdir/to-$main::desttype/$main::filetype/spec&quot;,
2453                 &quot;$workdir/$fields{NAME}-$fields{VERSION}-$fields{RELEASE}.spec&quot;,
2454                 %fields );</code></pre>
2455
2456 <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>
2457
2458 </dd>
2459 <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>
2460 <dd>
2461
2462 <p>In random testing, the following two alternating states</p>
2463
2464 <pre><code>    # State 1
2465     {
2466         if ( defined
2467         ($symbol_table{$direccion}) )
2468     }
2469
2470     # State 2
2471     {
2472         if (defined (
2473                 $symbol_table{
2474                     $direccion}
2475             )
2476         )
2477     }</code></pre>
2478
2479 <p>were occurring with the following particular parameter set</p>
2480
2481 <pre><code>    --weld-nested-containers
2482     --maximum-line-length=40
2483     --continuation-indentation=7
2484     --paren-tightness=2
2485     --extended-continuation-indentation</code></pre>
2486
2487 <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>
2488
2489 <pre><code>    {
2490         if (defined(
2491             $symbol_table{$direccion}
2492         ))
2493     }</code></pre>
2494
2495 <p>20 Jan 2021, 4021436.</p>
2496
2497 </dd>
2498 <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>
2499 <dd>
2500
2501 <p>A blinking state was found in random testing for the following snippet</p>
2502
2503 <pre><code>    =head1 TODO
2504
2505     handle UNIMARC encodings
2506
2507     =cut
2508
2509     use strict;
2510     use warnings;</code></pre>
2511
2512 <p>when run with the following parameters</p>
2513
2514 <pre><code>    --keyword-group-blanks-size=&#39;2.8&#39;
2515     --keyword-group-blanks-before=0</code></pre>
2516
2517 <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>
2518
2519 </dd>
2520 <dt id="Turn-off--boc-flag-if--iob-is-set"><b>Turn off -boc flag if -iob is set</b></dt>
2521 <dd>
2522
2523 <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>
2524
2525 </dd>
2526 <dt id="Modified-spacing-rule-for-token-type-Y"><b>Modified spacing rule for token type Y</b></dt>
2527 <dd>
2528
2529 <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>
2530
2531 </dd>
2532 <dt id="Fixed-blinker-related-to-line-break-at-indirect-object"><b>Fixed blinker related to line break at indirect object</b></dt>
2533 <dd>
2534
2535 <p>In random testing a blinker was reduced to the following snippet</p>
2536
2537 <pre><code>    {
2538              print FILE
2539               GD::Barcode
2540               -&gt;new();
2541     }</code></pre>
2542
2543 <p>which switched to the following state on each iteration</p>
2544
2545 <pre><code>    {
2546              print FILE GD::Barcode
2547               -&gt;new();
2548     }</code></pre>
2549
2550 <p>with the following parameters</p>
2551
2552 <pre><code>    --maximum-line-length=20
2553     --indent-columns=9
2554     --continuation-indentation=1</code></pre>
2555
2556 <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>
2557
2558 </dd>
2559 <dt id="Turn-off--bli-if--bar-is-set"><b>Turn off -bli if -bar is set</b></dt>
2560 <dd>
2561
2562 <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>
2563
2564 </dd>
2565 <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>
2566 <dd>
2567
2568 <p>A blinking state was discovered in testing between the following two states</p>
2569
2570 <pre><code>    my$table=
2571          [[1,2,3],[2,4,6],[3,6,9],
2572          ];
2573
2574     my$table=
2575         [[1,2,3],[2,4,6],[3,6,9],];</code></pre>
2576
2577 <p>with these parameters</p>
2578
2579 <pre><code>    --continuation-indentation=5
2580     --maximum-line-length=31
2581     --break-before-square-bracket-and-indent=2
2582     --break-before-square-bracket=1
2583     --noadd-whitespace</code></pre>
2584
2585 <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>
2586
2587 </dd>
2588 <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>
2589 <dd>
2590
2591 <p>In random testing with convergence a &#39;blinker&#39; (oscillating states) was found for the following script</p>
2592
2593 <pre><code>    sub _prompt {
2594
2595           print $_[0];
2596           return (
2597                 readline
2598                        (*{$_[1]})!~
2599                        /^q/i)
2600                  ; # Return false if user types &#39;q&#39;
2601
2602     }</code></pre>
2603
2604 <p>with the following specific parameters:</p>
2605
2606 <pre><code>    --maximum-line-length=32
2607     --indent-columns=6
2608     --continuation-indentation=7
2609     --weld-nested-containers
2610     --extended-continuation-indentation
2611     --noadd-whitespace</code></pre>
2612
2613 <p>The other state was</p>
2614
2615 <pre><code>    sub _prompt {
2616
2617           print $_[0];
2618           return (
2619                 readline(
2620                       *{
2621                             $_
2622                                    [
2623                                    1
2624                                    ]
2625                       }
2626                 )!~/^q/i
2627                  )
2628                  ; # Return false if user types &#39;q&#39;
2629
2630     }</code></pre>
2631
2632 <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>
2633
2634 </dd>
2635 <dt id="Fixed-incorrect-guess-of-division-vs-pattern"><b>Fixed incorrect guess of division vs pattern</b></dt>
2636 <dd>
2637
2638 <p>A syntax error was produced in random testing when perltidy was fed the following line:</p>
2639
2640 <pre><code>    sub _DR () { pi2 /360 } sub _RD () { 360 /pi2 }</code></pre>
2641
2642 <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>
2643
2644 <p>The formatted result is now</p>
2645
2646 <pre><code>    sub _DR () { pi2 / 360 }
2647     sub _RD () { 360 / pi2 }</code></pre>
2648
2649 <p>This update was made 13 Jan 2021, a50ecf8.</p>
2650
2651 </dd>
2652 <dt id="Correct-formula-for-estimating-line-length-with--wn-option"><b>Correct formula for estimating line length with -wn option</b></dt>
2653 <dd>
2654
2655 <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>
2656
2657 </dd>
2658 <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>
2659 <dd>
2660
2661 <p>The following blinker was found in random testing. The following statement (with @j starting at level 0)</p>
2662
2663 <pre><code>    @j = ( $x, $y, $z );</code></pre>
2664
2665 <p>run with the following parameters</p>
2666
2667 <pre><code>    --indent-columns=5
2668     --continuation-indentation=7
2669     --maximum-line-length=20
2670     --break-before-paren-and-indent=2
2671     --break-before-paren=2
2672     --maximum-fields-per-table=4</code></pre>
2673
2674 <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>
2675
2676 </dd>
2677 </dl>
2678
2679 <h1 id="Issues-fixed-after-release-20201207">Issues fixed after release 20201207</h1>
2680
2681 <dl>
2682
2683 <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>
2684 <dd>
2685
2686 <p>The indentation of multiline qw quotes runs into problems when there is nesting, as in the following.</p>
2687
2688 <pre><code>    # OLD: perltidy -xci -ci=4
2689     for my $feep (
2690         qw{
2691         pwage      pwchange   pwclass    pwcomment
2692         pwexpire   pwgecos    pwpasswd   pwquota
2693         }
2694         )</code></pre>
2695
2696 <p>The problem is that multiline qw quotes do not get the same indentation treatment as lists.</p>
2697
2698 <p>This update fixes this in the following circumstances:</p>
2699
2700 <pre><code>  - the leading qw( and trailing ) are on separate lines
2701   - the closing token is one of ) } ] &gt;
2702   - the -xci flag is set</code></pre>
2703
2704 <p>The above example becomes</p>
2705
2706 <pre><code>    # NEW: perltidy -xci -ci=4
2707     for my $feep (
2708         qw{
2709             pwage      pwchange   pwclass    pwcomment
2710             pwexpire   pwgecos    pwpasswd   pwquota
2711         }
2712         )</code></pre>
2713
2714 <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>
2715
2716 <pre><code>    # OLD and NEW: perltidy -wn -xci -ci=4
2717     for my $feep ( qw{
2718         pwage      pwchange   pwclass    pwcomment
2719         pwexpire   pwgecos    pwpasswd   pwquota
2720     } )</code></pre>
2721
2722 <p>This update added 8 Jan 2021, 474cfa8.</p>
2723
2724 </dd>
2725 <dt id="Improve-alignment-of-leading-equals-in-rare-situation"><b>Improve alignment of leading equals in rare situation</b></dt>
2726 <dd>
2727
2728 <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>
2729
2730 <pre><code>    # OLD:
2731     $them = &#39;localhost&#39; unless ( $them = shift );
2732     $cmd  = &#39;!print&#39;    unless ( $cmd  = shift );
2733     $port = 2345        unless ( $port = shift );
2734     $saddr = &#39;S n a4 x8&#39;;
2735     $SIG{&#39;INT&#39;} = &#39;dokill&#39;;
2736
2737     # NEW
2738     $them       = &#39;localhost&#39; unless ( $them = shift );
2739     $cmd        = &#39;!print&#39;    unless ( $cmd  = shift );
2740     $port       = 2345        unless ( $port = shift );
2741     $saddr      = &#39;S n a4 x8&#39;;
2742     $SIG{&#39;INT&#39;} = &#39;dokill&#39;;</code></pre>
2743
2744 <p>Fixed 5 Jan 2021, 9244678.</p>
2745
2746 </dd>
2747 <dt id="Moved-previous-patch-to-a-better-location"><b>Moved previous patch to a better location</b></dt>
2748 <dd>
2749
2750 <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>
2751
2752 </dd>
2753 <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>
2754 <dd>
2755
2756 <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>
2757
2758 <pre><code>    OLD: perltidy -sct -act=2
2759     foreach $line (
2760         [0, 1, 2], [3, 4, 5], [6, 7, 8],    # rows
2761         [0, 3, 6], [1, 4, 7], [2, 5, 8],    # columns
2762         [0, 4, 8], [2, 4, 6])                                     # diagonals
2763
2764     NEW: perltidy -sct -act=2
2765     foreach $line (
2766         [0, 1, 2], [3, 4, 5], [6, 7, 8],    # rows
2767         [0, 3, 6], [1, 4, 7], [2, 5, 8],    # columns
2768         [0, 4, 8], [2, 4, 6])    # diagonals</code></pre>
2769
2770 <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>
2771
2772 </dd>
2773 <dt id="Improve-rule-for-forgetting-last-side-comment-location"><b>Improve rule for forgetting last side comment location</b></dt>
2774 <dd>
2775
2776 <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>
2777
2778 <pre><code>        # OLD:
2779         foreach my $r (@$array) {
2780             $Dat{Data}{ uc $r-&gt;[0] } = join( &quot;;&quot;, @$r );    # store all info
2781             my $name = $Dat{GivenName}{ uc $r-&gt;[0] } || $r-&gt;[1];
2782
2783             # pass array as ad-hoc string, mark missing values
2784             $Dat{Data}{ uc $r-&gt;[0] } = join(
2785                 &quot;;&quot;,
2786                 (
2787                     uc $r-&gt;[0], uc $name,                   # symbol, name
2788                     $r-&gt;[2],    $r-&gt;[3], $r-&gt;[4],           # price, date, time
2789                     $r-&gt;[5],    $r-&gt;[6],                    # change, %change
2790                     $r-&gt;[7],    &quot;-&quot;, &quot;-&quot;, &quot;-&quot;,    # vol, avg vol, bid,ask
2791                     $r-&gt;[8],               $r-&gt;[9],     # previous, open
2792                     &quot;$r-&gt;[10] - $r-&gt;[11]&quot;, $r-&gt;[12],    # day range,year range,
2793                     &quot;-&quot;,                   &quot;-&quot;, &quot;-&quot;, &quot;-&quot;, &quot;-&quot;
2794                 )
2795             );                                          # eps,p/e,div,yld,cap
2796         }</code></pre>
2797
2798 <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>
2799
2800 <pre><code>        # NEW:
2801         foreach my $r (@$array) {
2802             $Dat{Data}{ uc $r-&gt;[0] } = join( &quot;;&quot;, @$r );    # store all info
2803             my $name = $Dat{GivenName}{ uc $r-&gt;[0] } || $r-&gt;[1];
2804
2805             # pass array as ad-hoc string, mark missing values
2806             $Dat{Data}{ uc $r-&gt;[0] } = join(
2807                 &quot;;&quot;,
2808                 (
2809                     uc $r-&gt;[0], uc $name,               # symbol, name
2810                     $r-&gt;[2],    $r-&gt;[3], $r-&gt;[4],       # price, date, time
2811                     $r-&gt;[5],    $r-&gt;[6],                # change, %change
2812                     $r-&gt;[7],    &quot;-&quot;, &quot;-&quot;, &quot;-&quot;,          # vol, avg vol, bid,ask
2813                     $r-&gt;[8],               $r-&gt;[9],     # previous, open
2814                     &quot;$r-&gt;[10] - $r-&gt;[11]&quot;, $r-&gt;[12],    # day range,year range,
2815                     &quot;-&quot;,                   &quot;-&quot;, &quot;-&quot;, &quot;-&quot;, &quot;-&quot;
2816                 )
2817             );    # eps,p/e,div,yld,cap
2818         }</code></pre>
2819
2820 <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>
2821
2822 <pre><code>    # OLD:
2823     {
2824         $a = [
2825             Cascade    =&gt; $menu_cb,
2826             -menuitems =&gt; [
2827                 [ Checkbutton =&gt; &#39;Oil checked&#39;, -variable =&gt; \$OIL ],
2828                 [
2829                     Button   =&gt; &#39;See current values&#39;,
2830                     -command =&gt; [
2831                         \&amp;see_vars, $TOP,
2832
2833                     ],    # end see_vars
2834                 ],        # end button
2835             ],            # end checkbutton menuitems
2836         ];                # end checkbuttons cascade
2837     }</code></pre>
2838
2839 <p>This was caused by forgetting side comments only across code block changes. The new result is more reasonable:</p>
2840
2841 <pre><code>    # NEW:
2842     {
2843         $a = [
2844             Cascade    =&gt; $menu_cb,
2845             -menuitems =&gt; [
2846                 [ Checkbutton =&gt; &#39;Oil checked&#39;, -variable =&gt; \$OIL ],
2847                 [
2848                     Button   =&gt; &#39;See current values&#39;,
2849                     -command =&gt; [
2850                         \&amp;see_vars, $TOP,
2851
2852                     ],    # end see_vars
2853                 ],    # end button
2854             ],    # end checkbutton menuitems
2855         ];    # end checkbuttons cascade
2856     }</code></pre>
2857
2858 <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>
2859
2860 </dd>
2861 <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>
2862 <dd>
2863
2864 <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>
2865
2866 <pre><code>            # OLD
2867             return join( &#39;&#39;,
2868                 $pre,   &#39;&lt;IMG &#39;,   $iconsizes{$alt} || &#39;&#39;,
2869                 $align, &#39;BORDER=&#39;, $nav_border,
2870                 &#39; ALT=&quot;&#39;, $alt,        &quot;\&quot;\n&quot;,
2871                 &#39; SRC=&quot;&#39;, $ICONSERVER, &quot;/$icon&quot;,
2872                 &#39;&quot;&gt;&#39; );
2873
2874             # NEW
2875             return join( &#39;&#39;,
2876                 $pre,     &#39;&lt;IMG &#39;,     $iconsizes{$alt} || &#39;&#39;,
2877                 $align,   &#39;BORDER=&#39;,   $nav_border,
2878                 &#39; ALT=&quot;&#39;, $alt,        &quot;\&quot;\n&quot;,
2879                 &#39; SRC=&quot;&#39;, $ICONSERVER, &quot;/$icon&quot;,
2880                 &#39;&quot;&gt;&#39; );</code></pre>
2881
2882 </dd>
2883 <dt id="Improved-vertical-alignment-of-some-edge-cases"><b>Improved vertical alignment of some edge cases</b></dt>
2884 <dd>
2885
2886 <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>
2887
2888 <pre><code>    # OLD:
2889     @gg_3 = (
2890         [
2891             0.0, 1.360755E-2, 9.569446E-4, 9.569446E-4,
2892             1.043498E-3, 1.043498E-3
2893         ],
2894         [
2895             9.569446E-4, 9.569446E-4, 0.0, 7.065964E-5,
2896             1.422811E-4, 1.422811E-4
2897         ],
2898         ...
2899     );
2900
2901     # NEW:
2902     @gg_3 = (
2903         [
2904             0.0,         1.360755E-2, 9.569446E-4, 9.569446E-4,
2905             1.043498E-3, 1.043498E-3
2906         ],
2907         [
2908             9.569446E-4, 9.569446E-4, 0.0, 7.065964E-5,
2909             1.422811E-4, 1.422811E-4
2910         ],
2911         ...
2912     );</code></pre>
2913
2914 <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>
2915
2916 </dd>
2917 <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>
2918 <dd>
2919
2920 <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>
2921
2922 <pre><code>    # OLD, perltidy -gnu
2923     @EXPORT = (
2924         qw(
2925           i Re Im rho theta arg
2926           sqrt log ln
2927           log10 logn cbrt root
2928           cplx cplxe
2929           ),
2930         @trig,
2931               );
2932
2933
2934     # NEW, perltidy -gnu
2935     @EXPORT = (
2936         qw(
2937           i Re Im rho theta arg
2938           sqrt log ln
2939           log10 logn cbrt root
2940           cplx cplxe
2941         ),
2942         @trig,
2943     );</code></pre>
2944
2945 <p>27-Dec-2020, 948c9bd.</p>
2946
2947 </dd>
2948 <dt id="improve-formatting-of-multiline-qw"><b>improve formatting of multiline qw</b></dt>
2949 <dd>
2950
2951 <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>
2952
2953 <pre><code>    # OLD, perltidy -wn
2954     # qw line
2955     if ( $pos == 0 ) {
2956         @return = grep( /^$word/,
2957             sort qw(
2958               ! a b d h i m o q r u autobundle clean
2959               make test install force reload look
2960         ) ); #&lt;-- outdented more than &#39;sort&#39;
2961     }
2962
2963     # Here is the same with a list instead of a qw; note how the
2964     # closing sort paren does not outdent more than the &#39;sort&#39; line.
2965     # This is the desired result for qw.
2966     # perltidy -wn
2967     if ( $pos == 0 ) {
2968         @return = grep( /^$word/,
2969             sort (
2970
2971                 &#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;,
2972                 &#39;autobundle&#39;, &#39;clean&#39;,
2973                 &#39;make&#39;,       &#39;test&#39;, &#39;install&#39;, &#39;force&#39;, &#39;reload&#39;, &#39;look&#39;
2974             ) );  #&lt;-- not outdented more than &#39;sort&#39;
2975     }
2976
2977     # NEW (perltidy -wn)
2978     if ( $pos == 0 ) {
2979         @return = grep( /^$word/,
2980             sort qw(
2981               ! a b d h i m o q r u autobundle clean
2982               make test install force reload look
2983             ) ); #&lt;-- not outdented more than sort
2984     }</code></pre>
2985
2986 <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>
2987
2988 <pre><code>        Class::XYZ::Overload
2989     );  #&lt;-- outdented more than the line with &#39;for qw(&#39;
2990
2991     # NEW:
2992     $_-&gt;meta-&gt;make_immutable(
2993         inline_constructor =&gt; 0,
2994         constructor_name   =&gt; &quot;_new&quot;,
2995         inline_accessors   =&gt; 0,
2996       )
2997       for qw(
2998       Class::XYZ::Package
2999       Class::XYZ::Module
3000       Class::XYZ::Class
3001
3002       Class::XYZ::Overload
3003       ); #&lt;-- outdented same as the line with &#39;for qw(&#39;</code></pre>
3004
3005 <p>26 Dec 2020, cdbf0e4.</p>
3006
3007 </dd>
3008 <dt id="improve-list-marking-method"><b>improve list marking method</b></dt>
3009 <dd>
3010
3011 <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>
3012
3013 <pre><code>    # OLD
3014     return (
3015         $startpos, $ldelpos - $startpos,         # PREFIX
3016         $ldelpos,  1,                            # OPENING BRACKET
3017         $ldelpos + 1, $endpos - $ldelpos - 2,    # CONTENTS
3018         $endpos - 1, 1,                          # CLOSING BRACKET
3019         $endpos, length($$textref) - $endpos,    # REMAINDER
3020     );
3021
3022     # NEW
3023     return (
3024         $startpos,    $ldelpos - $startpos,           # PREFIX
3025         $ldelpos,     1,                              # OPENING BRACKET
3026         $ldelpos + 1, $endpos - $ldelpos - 2,         # CONTENTS
3027         $endpos - 1,  1,                              # CLOSING BRACKET
3028         $endpos,      length($$textref) - $endpos,    # REMAINDER
3029     );</code></pre>
3030
3031 <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>
3032
3033 <pre><code>    # OLD: (undesirable alignment)
3034     my ( $isig2, $chisq ) = ( 1 / ( $sig * $sig ), 0 );
3035     my ( $ym,    $al, $cov, $bet, $olda, $ochisq, $di, $pivt, $info ) =
3036       map { null } ( 0 .. 8 );
3037
3038     # NEW: (no alignment)
3039     my ( $isig2, $chisq ) = ( 1 / ( $sig * $sig ), 0 );
3040     my ( $ym, $al, $cov, $bet, $olda, $ochisq, $di, $pivt, $info ) =
3041       map { null } ( 0 .. 8 );</code></pre>
3042
3043 <p>This update was made 22 Dec 2020, 36d4c35.</p>
3044
3045 </dd>
3046 <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>
3047 <dd>
3048
3049 <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>
3050
3051 <pre><code>    # OLD:
3052     @EXPORT = (
3053         qw(
3054           i Re Im rho theta arg
3055           sqrt log ln
3056           log10 logn cbrt root
3057           cplx cplxe
3058           ),
3059         @trig
3060     );
3061
3062     # NEW
3063     @EXPORT = (
3064         qw(
3065             i Re Im rho theta arg
3066             sqrt log ln
3067             log10 logn cbrt root
3068             cplx cplxe
3069         ),
3070         @trig
3071     );</code></pre>
3072
3073 <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>
3074
3075 <pre><code>    @EXPORT = (
3076         qw&lt;
3077           i Re Im rho theta arg
3078           sqrt log ln
3079           log10 logn cbrt root
3080           cplx cplxe
3081         &gt;,
3082         @trig
3083     );</code></pre>
3084
3085 <p>but (&#39;;&#39; remains indented):</p>
3086
3087 <pre><code>    @EXPORT = (
3088         qw;
3089           i Re Im rho theta arg
3090           sqrt log ln
3091           log10 logn cbrt root
3092           cplx cplxe
3093           ;,
3094         @trig
3095     );</code></pre>
3096
3097 <p>This update was added 18 Dec 2020 and modified 24 Dec 2020, 538688f.</p>
3098
3099 </dd>
3100 <dt id="Update-manual-pages-regarding-issue-git-50"><b>Update manual pages regarding issue git #50</b></dt>
3101 <dd>
3102
3103 <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>
3104
3105 </dd>
3106 <dt id="Rewrote-sub-check_match"><b>Rewrote sub check_match</b></dt>
3107 <dd>
3108
3109 <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>
3110
3111 <pre><code>    # OLD:
3112     @tests = (
3113         @common,     &#39;$_&#39;,
3114         &#39;&quot;\$_&quot;&#39;,     &#39;@_&#39;,
3115         &#39;&quot;\@_&quot;&#39;,     &#39;??N&#39;,
3116         &#39;&quot;??N&quot;&#39;,     chr 256,
3117         &#39;&quot;\x{100}&quot;&#39;, chr 65536,
3118         &#39;&quot;\x{10000}&quot;&#39;, ord &#39;N&#39; == 78 ? ( chr 11, &#39;&quot;\013&quot;&#39; ) : ()
3119     );
3120
3121     # NEW:
3122     @tests = (
3123         @common,       &#39;$_&#39;,
3124         &#39;&quot;\$_&quot;&#39;,       &#39;@_&#39;,
3125         &#39;&quot;\@_&quot;&#39;,       &#39;??N&#39;,
3126         &#39;&quot;??N&quot;&#39;,       chr 256,
3127         &#39;&quot;\x{100}&quot;&#39;,   chr 65536,
3128         &#39;&quot;\x{10000}&quot;&#39;, ord &#39;N&#39; == 78 ? ( chr 11, &#39;&quot;\013&quot;&#39; ) : ()
3129     );</code></pre>
3130
3131 </dd>
3132 <dt id="Improved-vertical-alignments-by-avoiding-pruning-step"><b>Improved vertical alignments by avoiding pruning step</b></dt>
3133 <dd>
3134
3135 <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>
3136
3137 <pre><code>    # OLD
3138     my $cmd = shift @ARGV;
3139     if    ( $cmd eq &quot;new&quot; )         { $force_new = 1; }
3140     elsif ( $cmd eq &quot;interactive&quot; ) { $interactive = 1; $batch       = 0; }
3141     elsif ( $cmd eq &quot;batch&quot; )       { $batch       = 1; $interactive = 0; }
3142     elsif ( $cmd eq &quot;use_old&quot; )     { $use_old = 1; }
3143     elsif ( $cmd eq &quot;show&quot; )        { $show    = 1; last; }
3144     elsif ( $cmd eq &quot;showall&quot; )     { $showall = 1; last; }
3145     elsif ( $cmd eq &quot;show_all&quot; )    { $showall = 1; last; }
3146     elsif ( $cmd eq &quot;remove&quot; )      { $remove  = 1; last; }
3147     elsif ( $cmd eq &quot;help&quot; )        { $help    = 1; last; }
3148
3149     # NEW
3150     my $cmd = shift @ARGV;
3151     if    ( $cmd eq &quot;new&quot; )         { $force_new   = 1; }
3152     elsif ( $cmd eq &quot;interactive&quot; ) { $interactive = 1; $batch       = 0; }
3153     elsif ( $cmd eq &quot;batch&quot; )       { $batch       = 1; $interactive = 0; }
3154     elsif ( $cmd eq &quot;use_old&quot; )     { $use_old     = 1; }
3155     elsif ( $cmd eq &quot;show&quot; )        { $show        = 1; last; }
3156     elsif ( $cmd eq &quot;showall&quot; )     { $showall     = 1; last; }
3157     elsif ( $cmd eq &quot;show_all&quot; )    { $showall     = 1; last; }
3158     elsif ( $cmd eq &quot;remove&quot; )      { $remove      = 1; last; }
3159     elsif ( $cmd eq &quot;help&quot; )        { $help        = 1; last; }</code></pre>
3160
3161 <p>This update was made 14 Dec 2020, 44e0afa.</p>
3162
3163 </dd>
3164 <dt id="Improved-some-marginal-vertical-alignments"><b>Improved some marginal vertical alignments</b></dt>
3165 <dd>
3166
3167 <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>
3168
3169 <pre><code>    # OLD
3170     $sec = $sec + ( 60 * $min );
3171     $graphcpu[$sec] = $line;
3172     $secmax  = $sec  if ( $sec &gt; $secmax );
3173     $linemax = $line if ( $line &gt; $linemax );
3174
3175     # NEW
3176     $sec            = $sec + ( 60 * $min );
3177     $graphcpu[$sec] = $line;
3178     $secmax         = $sec  if ( $sec &gt; $secmax );
3179     $linemax        = $line if ( $line &gt; $linemax );</code></pre>
3180
3181 </dd>
3182 <dt id="Do-not-align-equals-across-changes-in-continuation-indentation"><b>Do not align equals across changes in continuation indentation</b></dt>
3183 <dd>
3184
3185 <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>
3186
3187 <pre><code>    # BAD:
3188     $!               = 2, die qq/$0: can&#39;t stat -${arg}&#39;s &quot;$file&quot;./
3189         unless $time = ( stat($file) )[$STAT_MTIME];
3190
3191     # FIXED:
3192     $! = 2, die qq/$0: can&#39;t stat -${arg}&#39;s &quot;$file&quot;./
3193       unless $time = ( stat($file) )[$STAT_MTIME];</code></pre>
3194
3195 <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>
3196
3197 </dd>
3198 <dt id="Improve-vertical-alignment-in-some-two-line-matches"><b>Improve vertical alignment in some two-line matches</b></dt>
3199 <dd>
3200
3201 <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>
3202
3203 <p># In this example the side comments were limiting the matches</p>
3204
3205 <pre><code>    # OLD
3206     shift @data if @data and $data[0] =~ /Contributed\s+Perl/;    # Skip header
3207     pop @data if @data and $data[-1] =~ /^\w/;    # Skip footer, like
3208
3209     # NEW
3210     shift @data if @data and $data[0]  =~ /Contributed\s+Perl/;    # Skip header
3211     pop @data   if @data and $data[-1] =~ /^\w/;    # Skip footer, like</code></pre>
3212
3213 <p># The same is true here.</p>
3214
3215 <pre><code>    # OLD
3216     if ($tvg::o_span) { $tvg::hour_span = $tvg::o_span; }
3217     if ( $tvg::hour_span % 2 &gt; 0 ) { $tvg::hour_span++; }    # Multiple of 2
3218
3219     # NEW
3220     if ($tvg::o_span)              { $tvg::hour_span = $tvg::o_span; }
3221     if ( $tvg::hour_span % 2 &gt; 0 ) { $tvg::hour_span++; }    # Multiple of 2</code></pre>
3222
3223 <p>In the next example, the first comma is now aligned but not the second, because of the line length limit:</p>
3224
3225 <pre><code>    # OLD
3226     is( MyClass-&gt;meta, $mc, &#39;... these metas are still the same thing&#39; );
3227     is( MyClass-&gt;meta-&gt;meta, $mc-&gt;meta, &#39;... these meta-metas are the same thing&#39; );
3228
3229     # NEW
3230     is( MyClass-&gt;meta,       $mc, &#39;... these metas are still the same thing&#39; );
3231     is( MyClass-&gt;meta-&gt;meta, $mc-&gt;meta, &#39;... these meta-metas are the same thing&#39; );</code></pre>
3232
3233 <p>In this last example, the first comma is not aligned, but alignment resumes after the second comma.</p>
3234
3235 <pre><code>    # OLD
3236     is( $obj-&gt;name, $COMPRESS_FILE, &quot;   Name now set to &#39;$COMPRESS_FILE&#39;&quot; );
3237     is( $obj-&gt;prefix, &#39;&#39;, &quot;   Prefix now empty&quot; );
3238
3239     # NEW
3240     is( $obj-&gt;name, $COMPRESS_FILE, &quot;   Name now set to &#39;$COMPRESS_FILE&#39;&quot; );
3241     is( $obj-&gt;prefix, &#39;&#39;,           &quot;   Prefix now empty&quot; );</code></pre>
3242
3243 </dd>
3244 <dt id="Improve-vertical-alignment-in-some-marginal-matches"><b>Improve vertical alignment in some marginal matches</b></dt>
3245 <dd>
3246
3247 <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>
3248
3249 <pre><code>    # OLD
3250     my @roles = $self-&gt;role_names;
3251     my $role_names = join &quot;|&quot;, @roles;
3252
3253     # NEW
3254     my @roles      = $self-&gt;role_names;
3255     my $role_names = join &quot;|&quot;, @roles;
3256
3257     # OLD
3258     $sysname .= &#39;del&#39; if $self-&gt;label =~ /deletion/;
3259     $sysname .= &#39;ins&#39; if $self-&gt;label =~ /insertion/;
3260     $sysname .= uc $self-&gt;allele_ori-&gt;seq if $self-&gt;allele_ori-&gt;seq;
3261
3262     # NEW
3263     $sysname .= &#39;del&#39;                     if $self-&gt;label =~ /deletion/;
3264     $sysname .= &#39;ins&#39;                     if $self-&gt;label =~ /insertion/;
3265     $sysname .= uc $self-&gt;allele_ori-&gt;seq if $self-&gt;allele_ori-&gt;seq;</code></pre>
3266
3267 </dd>
3268 <dt id="Improve-vertical-alignment-of-lines-ending-in-fat-comma"><b>Improve vertical alignment of lines ending in fat comma</b></dt>
3269 <dd>
3270
3271 <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>
3272
3273 <pre><code>    # OLD
3274     $template-&gt;param(
3275         classlist =&gt; $classlist,
3276         ...,
3277         suggestion =&gt; $suggestion,
3278         totspent   =&gt; sprintf( &quot;%.2f&quot;, $totspent ),
3279         totcomtd   =&gt; sprintf( &quot;%.2f&quot;, $totcomtd ),
3280         totavail   =&gt; sprintf( &quot;%.2f&quot;, $totavail ),
3281         nobudget =&gt; $#results == -1 ? 1 : 0,
3282         intranetcolorstylesheet =&gt;
3283           C4::Context-&gt;preference(&quot;intranetcolorstylesheet&quot;),
3284         ...
3285     );
3286
3287     # NEW
3288     $template-&gt;param(
3289         classlist =&gt; $classlist,
3290         ...,
3291         suggestion              =&gt; $suggestion,
3292         totspent                =&gt; sprintf( &quot;%.2f&quot;, $totspent ),
3293         totcomtd                =&gt; sprintf( &quot;%.2f&quot;, $totcomtd ),
3294         totavail                =&gt; sprintf( &quot;%.2f&quot;, $totavail ),
3295         nobudget                =&gt; $#results == -1 ? 1 : 0,
3296         intranetcolorstylesheet =&gt;
3297           C4::Context-&gt;preference(&quot;intranetcolorstylesheet&quot;),
3298         ...
3299     );</code></pre>
3300
3301 </dd>
3302 <dt id="Avoid-processing-a-file-more-than-once"><b>Avoid processing a file more than once</b></dt>
3303 <dd>
3304
3305 <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>
3306
3307 <pre><code>  perltidy file1.pl file1.pl </code></pre>
3308
3309 <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>
3310
3311 </dd>
3312 <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>
3313 <dd>
3314
3315 <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>
3316
3317 </dd>
3318 </dl>
3319
3320 <h1 id="Issues-fixed-after-release-20201202">Issues fixed after release 20201202</h1>
3321
3322 <dl>
3323
3324 <dt id="Fix-for-issue-git-47"><b>Fix for issue git #47</b></dt>
3325 <dd>
3326
3327 <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>
3328
3329 <pre><code>    $promises[$i]-&gt;then(
3330         sub { $all-&gt;resolve(@_); () },
3331         sub {
3332             $results-&gt;[$i] = [@_];
3333             $all-&gt;reject(@$results) if --$remaining &lt;= 0;
3334             return ();
3335         }
3336     );</code></pre>
3337
3338 <p>A bug introduced in v20201202 caused an incorrect welding to occur when the -wn flag was set</p>
3339
3340 <pre><code>    $promises[$i]-&gt;then( sub { $all-&gt;resolve(@_); () },
3341         sub {
3342         $results-&gt;[$i] = [@_];
3343         $all-&gt;reject(@$results) if --$remaining &lt;= 0;
3344         return ();
3345         } );</code></pre>
3346
3347 <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>
3348
3349 </dd>
3350 </dl>
3351
3352 <h1 id="Issues-fixed-after-release-20201001">Issues fixed after release 20201001</h1>
3353
3354 <dl>
3355
3356 <dt id="removed-excess-spaces-in-a-package-declaration"><b>removed excess spaces in a package declaration</b></dt>
3357 <dd>
3358
3359 <p>Testing revealed that for a line such as</p>
3360
3361 <pre><code>   package        Bob::Dog;</code></pre>
3362
3363 <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>
3364
3365 <pre><code>    package Bob::Dog;</code></pre>
3366
3367 </dd>
3368 <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>
3369 <dd>
3370
3371 <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>
3372
3373 </dd>
3374 <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>
3375 <dd>
3376
3377 <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>
3378
3379 </dd>
3380 <dt id="fix-for-formatting-signed-numbers-with-spaces"><b>fix for formatting signed numbers with spaces</b></dt>
3381 <dd>
3382
3383 <p>In developing an improved convergence test, an issue slowing convergence was found related to signed numbers as in the following line,</p>
3384
3385 <pre><code>    @london = (deg2rad(-  0.5), deg2rad(90 - 51.3));</code></pre>
3386
3387 <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>
3388
3389 <pre><code>    @london = ( deg2rad( -0.5 ), deg2rad( 90 - 51.3 ) );</code></pre>
3390
3391 <p>The next time it is formatted, the &#39;-0.5&#39; counts as one token, resulting in</p>
3392
3393 <pre><code>    @london = ( deg2rad(-0.5), deg2rad( 90 - 51.3 ) );</code></pre>
3394
3395 <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>
3396
3397 </dd>
3398 <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>
3399 <dd>
3400
3401 <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>
3402
3403 <pre><code>    sub macro_get_names {    #
3404     #
3405     # %name = macro_get_names();  (key=macrohandle, value=macroname)
3406     #
3407         local (%name) = ();
3408         ...
3409     }</code></pre>
3410
3411 <p>For the following specific contitions the block comment in line 2 could be converted into a hanging side comment, which is undesirable:</p>
3412
3413 <pre><code>   1. The line contains nothing except for a &#39;#&#39; with no leading space
3414    2. It follows a line with side comment
3415    3. It has indentation level &gt; 0</code></pre>
3416
3417 <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>
3418
3419 </dd>
3420 <dt id="improved-convergence-test"><b>improved convergence test</b></dt>
3421 <dd>
3422
3423 <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>
3424
3425 </dd>
3426 <dt id="fixed-problem-with-vertical-alignments-involving-if-statements"><b>fixed problem with vertical alignments involving &#39;if&#39; statements</b></dt>
3427 <dd>
3428
3429 <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>
3430
3431 <pre><code>  OLD:
3432     $m1 = 0;
3433     if ( $value =~ /\bset\b/i )      { $m0 = 1; }
3434     if ( $value =~ /\barithmetic/i ) { $m1 = 1; }
3435     if    ( $m0 &amp;&amp; !$m1 ) { $CONFIG[1] = 0; }
3436     elsif ( !$m0 &amp;&amp; $m1 ) { $CONFIG[1] = 1; }
3437     else                  { $ok        = 0; last; }
3438
3439  NEW:
3440     $m1 = 0;
3441     if    ( $value =~ /\bset\b/i )      { $m0        = 1; }
3442     if    ( $value =~ /\barithmetic/i ) { $m1        = 1; }
3443     if    ( $m0 &amp;&amp; !$m1 )               { $CONFIG[1] = 0; }
3444     elsif ( !$m0 &amp;&amp; $m1 )               { $CONFIG[1] = 1; }
3445     else                                { $ok        = 0; last; }</code></pre>
3446
3447 <p>This update was made 15 Nov 2020, 2b7784d.</p>
3448
3449 </dd>
3450 <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>
3451 <dd>
3452
3453 <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>
3454
3455 </dd>
3456 <dt id="merged-pull-request-git-46"><b>merged pull request git #46</b></dt>
3457 <dd>
3458
3459 <p>The man page gave the incorrect string for -fse. This was fixed 11 Nov 2020 in 1f9869e.</p>
3460
3461 </dd>
3462 <dt id="recognize-overloaded-RPerl-operators-to-avoid-error-messages"><b>recognize overloaded RPerl operators to avoid error messages</b></dt>
3463 <dd>
3464
3465 <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>
3466
3467 </dd>
3468 <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>
3469 <dd>
3470
3471 <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>
3472
3473 </dd>
3474 <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>
3475 <dd>
3476
3477 <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>
3478
3479 </dd>
3480 <dt id="added-parameters--maxue-n-and-maxle-n"><b>added parameters -maxue=n and maxle=n</b></dt>
3481 <dd>
3482
3483 <p>These parameters had tentatively been hardwired in the tokenizer. Now the user can control them or turn the checks off altogether.</p>
3484
3485 </dd>
3486 <dt id="Fix-problem-parsing"><b>Fix problem parsing &#39;$$*&#39;</b></dt>
3487 <dd>
3488
3489 <p>In random testing, an error was encountered parsing the following line</p>
3490
3491 <pre><code>  $self-&gt;{&quot;mod_id&quot;}=($$*1001)%(10**(rand()*6));
3492                        ---^
3493   found Number where operator expected (previous token underlined)</code></pre>
3494
3495 <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>
3496
3497 </dd>
3498 <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>
3499 <dd>
3500
3501 <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>
3502
3503 </dd>
3504 <dt id="Fixed-problem-parsing-extruded-signature"><b>Fixed problem parsing extruded signature</b></dt>
3505 <dd>
3506
3507 <p>A parsing error was encountered in a test parsing the following extruded signature:</p>
3508
3509 <pre><code>  sub foo2
3510   (
3511   $
3512   first
3513   ,
3514   $
3515   ,
3516   $
3517   third
3518   )
3519   {
3520   return
3521   &quot;first=$first, third=$third&quot;
3522   ;
3523   }</code></pre>
3524
3525 <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>
3526
3527 <p>The file parses correctly now, with formatted output</p>
3528
3529 <pre><code>  sub foo2 ( $first, $, $third ) {
3530       return &quot;first=$first, third=$third&quot;;
3531   }</code></pre>
3532
3533 </dd>
3534 <dt id="Fixed-several-uses-of-undefined-variables-found-in-testing"><b>Fixed several uses of undefined variables found in testing</b></dt>
3535 <dd>
3536
3537 <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>
3538
3539 </dd>
3540 <dt id="Prevent-syntax-error-by-breaking-dashed-package-names"><b>Prevent syntax error by breaking dashed package names</b></dt>
3541 <dd>
3542
3543 <p>In stress testing perltidy with the -extrude option, the following test snippet</p>
3544
3545 <pre><code>  use perl6-alpha;</code></pre>
3546
3547 <p>was broken into sepate lines</p>
3548
3549 <pre><code>  use
3550   perl6
3551   -
3552   alpha
3553   ;</code></pre>
3554
3555 <p>A rule was added to prevent breaking around a dash separating two barewords. Rerunning gives</p>
3556
3557 <pre><code>  use
3558   perl6-alpha
3559   ;</code></pre>
3560
3561 <p>This was fixed 26 Oct 2020 in &#39;prevent breaking package names with trailing dashes&#39;, 9234be4.</p>
3562
3563 </dd>
3564 <dt id="Prevent-syntax-error-by-breaking-dashed-barewords"><b>Prevent syntax error by breaking dashed barewords</b></dt>
3565 <dd>
3566
3567 <p>In stress testing perltidy with the -extrude option, using the following test snippet</p>
3568
3569 <pre><code>  my %var;
3570   {
3571       $var{-y}  = 1;
3572       $var{-q}  = 1;
3573       $var{-qq} = 1;
3574       $var{-m}  = 1;
3575       $var{y}   = 1;
3576       $var{q}   = 1;
3577       $var{qq}  = 1;
3578       $var{m}   = 1;
3579   }</code></pre>
3580
3581 <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>
3582
3583 <pre><code>  my%var
3584   ;
3585   {
3586   $var{-y}
3587   =
3588   1
3589   ;
3590   $var{-q}
3591   =
3592   1
3593   ;
3594   $var{-qq}
3595   =
3596   1
3597   ;
3598   $var{-m}
3599   =
3600   1
3601   ;
3602   $var{y}
3603   =
3604   1
3605   ;
3606   $var{q}
3607   =
3608   1
3609   ;
3610   $var{qq}
3611   =
3612   1
3613   ;
3614   $var{m}
3615   =
3616   1
3617   ;
3618   }</code></pre>
3619
3620 <p>This update was added 26 Oct 2020, &#39;prevent syntax error by breaking dashed barewords&#39;, e121cae.</p>
3621
3622 </dd>
3623 <dt id="more-types-of-severe-errors-will-prevent-formatting"><b>more types of severe errors will prevent formatting</b></dt>
3624 <dd>
3625
3626 <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>
3627
3628 <pre><code>  {{{{
3629   }}</code></pre>
3630
3631 <p>was previously output with default parameters as</p>
3632
3633 <pre><code>  {
3634       {
3635           {
3636               {}
3637           }</code></pre>
3638
3639 <p>along with an error message. But now it is just output verbatim as</p>
3640
3641 <pre><code>  {{{{
3642   }}</code></pre>
3643
3644 <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>
3645
3646 </dd>
3647 <dt id="added-state-as-keyword"><b>added &#39;state&#39; as keyword</b></dt>
3648 <dd>
3649
3650 <p>A statement such as the following was generating an error message at the colon:</p>
3651
3652 <pre><code>   state $a : shared;</code></pre>
3653
3654 <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>
3655
3656 </dd>
3657 <dt id="sub-signatures-no-longer-parsed-with-prototypes"><b>sub signatures no longer parsed with prototypes</b></dt>
3658 <dd>
3659
3660 <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>
3661
3662 <pre><code> # Old, input and after formatting:
3663  sub t123 ($list=wantarray) { $list ? &quot;list&quot; : &quot;scalar&quot; }
3664
3665  # New, after formatting
3666  sub t123 ( $list = wantarray ) { $list ? &quot;list&quot; : &quot;scalar&quot; }</code></pre>
3667
3668 <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>
3669
3670 <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>
3671
3672 <pre><code>  # perltidy -sal=&#39;method&#39;
3673   method foo4 ( $class : $bar, $bubba ) { $class-&gt;bar($bar) }</code></pre>
3674
3675 <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>
3676
3677 <pre><code>  # perltidy -sal=&#39;method&#39; -nwls=&#39;A&#39;
3678   method foo4 ( $class: $bar, $bubba ) { $class-&gt;bar($bar) }</code></pre>
3679
3680 <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>
3681
3682 </dd>
3683 <dt id="fix-parsing-problem-with"><b>fix parsing problem with $#</b></dt>
3684 <dd>
3685
3686 <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>
3687
3688 <pre><code>    my $ #
3689     #
3690     ans = 40;</code></pre>
3691
3692 <p>This was being misparsed and was fixed 17 Oct 2020, in &#39;fixed parsing error with spaces in $#&#39; a079cdb.</p>
3693
3694 </dd>
3695 <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>
3696 <dd>
3697
3698 <p>During testing the following error was found and fixed. Given the following input snippet:</p>
3699
3700 <pre><code>    get(
3701         on_ready =&gt; sub ($worker) {
3702             $on_ready-&gt;end;
3703             return;
3704         },
3705         on_exit =&gt; sub ( $worker, $status ) { return; },
3706     );</code></pre>
3707
3708 <p>The resulting formatting was</p>
3709
3710 <pre><code>    get(
3711         on_ready =&gt; sub ($worker) {
3712             $on_ready-&gt;end;
3713             return;
3714         }, on_exit =&gt; sub ( $worker, $status ) { return; },
3715     );</code></pre>
3716
3717 <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>
3718
3719 </dd>
3720 <dt id="fix-issues-with-prototype-and-signature-parsing"><b>fix issues with prototype and signature parsing</b></dt>
3721 <dd>
3722
3723 <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>
3724
3725 <pre><code>    sub test ( # comment )))
3726         $x, $x) { $x+$y }</code></pre>
3727
3728 <p>Complex signature expressions such as the following are now parsed without error:</p>
3729
3730 <pre><code>    sub t086
3731         ( #foo)))
3732         $ #foo)))
3733         a #foo)))
3734         ) #foo)))
3735         { $a.$b }</code></pre>
3736
3737 </dd>
3738 <dt id="improve-guess-for-pattern-or-division"><b>improve guess for pattern or division</b></dt>
3739 <dd>
3740
3741 <p>The following line caused a tokenization error in which the two slashes were parsed as a pattern.</p>
3742
3743 <pre><code>   my $masksize = ceil( Opcode::opcodes / 8 );    # /</code></pre>
3744
3745 <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>
3746
3747 </dd>
3748 <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>
3749 <dd>
3750
3751 <p>The flag <b>-bos</b>, or <b>--break-at-old-semicolon-breakpoints</b>, keeps breaks at old isolated semicolons. For example</p>
3752
3753 <pre><code>    $z = sqrt($x**2 + $y**2)
3754       ;</code></pre>
3755
3756 <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>
3757
3758 <pre><code>    my $dist = sub {
3759         $z = sqrt( $x**2 + $y**2 )
3760           ;
3761       }
3762       ;</code></pre>
3763
3764 </dd>
3765 <dt id="keep-break-after-use-overload"><b>keep break after &#39;use overload&#39;</b></dt>
3766 <dd>
3767
3768 <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>
3769
3770 <pre><code>                use overload
3771                     &#39;+&#39; =&gt; sub {
3772                         print length $_[2], &quot;\n&quot;;
3773                         my ( $x, $y ) = _order(@_);
3774                         Number::Roman-&gt;new( int $x + $y );
3775                     },
3776                     &#39;-&#39; =&gt; sub {
3777                         my ( $x, $y ) = _order(@_);
3778                         Number::Roman-&gt;new( int $x - $y );
3779                     },
3780                     ...</code></pre>
3781
3782 <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>
3783
3784 </dd>
3785 <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>
3786 <dd>
3787
3788 <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>
3789
3790 </dd>
3791 <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>
3792 <dd>
3793
3794 <p>This problem is illustrated with the following snippet when run with -bli -blil=&#39;*&#39;</p>
3795
3796 <pre><code>    #-bli -bli list=&#39;*&#39;
3797     try
3798       {
3799         die;
3800       }
3801     catch
3802       {
3803         die;
3804       };    # &lt;-- this was not indenting</code></pre>
3805
3806 <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>
3807
3808 <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>
3809
3810 <pre><code>  # perltidy -bli -blil=&#39;*&#39;
3811     eval
3812       {
3813         my $app = App::perlbrew-&gt;new( &quot;install-patchperl&quot;, &quot;-q&quot; );
3814         $app-&gt;run();
3815       }
3816       or do
3817       {
3818         $error          = $@;
3819         $produced_error = 1;
3820       };</code></pre>
3821
3822 </dd>
3823 </dl>
3824
3825 <h1 id="Issues-fixed-after-release-20200907">Issues fixed after release 20200907</h1>
3826
3827 <p>This is a detailed log of changes since the release 20200907. All bugs were found with the help of automated random testing.</p>
3828
3829 <dl>
3830
3831 <dt id="Keep-any-space-between-a-bareword-and-quote"><b>Keep any space between a bareword and quote</b></dt>
3832 <dd>
3833
3834 <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>
3835
3836 <pre><code>  oops&quot;Your login, $Bad_Login, is not valid&quot;;</code></pre>
3837
3838 <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>
3839
3840 </dd>
3841 <dt id="Fixed-some-incorrect-indentation-disagreements-reported-in-LOG-file"><b>Fixed some incorrect indentation disagreements reported in LOG file</b></dt>
3842 <dd>
3843
3844 <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>
3845
3846 </dd>
3847 <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>
3848 <dd>
3849
3850 <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>
3851
3852 </dd>
3853 <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>
3854 <dd>
3855
3856 <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>
3857
3858 </dd>
3859 <dt id="fixed-uninitialized-value-reference"><b>fixed uninitialized value reference</b></dt>
3860 <dd>
3861
3862 <p>The following message was generated during automated testing</p>
3863
3864 <pre><code> Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 12079.
3865  Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 12089.
3866  Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 12097.</code></pre>
3867
3868 <p>The problem could be simplified to running perltidy -wn on this snippet:</p>
3869
3870 <pre><code>     __PACKAGE__-&gt;load_components( qw(
3871 &gt;         Core
3872 &gt;
3873 &gt;     ) );</code></pre>
3874
3875 <p>This was fixed 20 Sep 2020 in &#39;fixed_uninitialized_value&#39;, 8d6c4ed.</p>
3876
3877 </dd>
3878 <dt id="fix-incorrect-parsing-of-certain-deprecated-empty-here-docs"><b>fix incorrect parsing of certain deprecated empty here-docs </b></dt>
3879 <dd>
3880
3881 <p>The following snippet was being incorrectly parsed:</p>
3882
3883 <pre><code> print &lt;&lt;
3884  # Hello World 13!
3885
3886    ;
3887  print &quot;DONE\n&quot;;</code></pre>
3888
3889 <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>
3890
3891 <p>This was found in random testing and fixed 16 Sep 2020. A warning message about deprecated here-doc targets was added.</p>
3892
3893 </dd>
3894 <dt id="make-the-arrow-a-vertical-alignment-token-git-39"><b>make the arrow a vertical alignment token, git #39</b></dt>
3895 <dd>
3896
3897 <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>
3898
3899 </dd>
3900 <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>
3901 <dd>
3902
3903 <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>
3904
3905 </dd>
3906 <dt id="Allow-vertical-alignment-of-line-ending-fat-comma"><b>Allow vertical alignment of line-ending fat comma</b></dt>
3907 <dd>
3908
3909 <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>
3910
3911 </dd>
3912 <dt id="fixed-uninitialized-value-reference1"><b>fixed uninitialized value reference</b></dt>
3913 <dd>
3914
3915 <p>The following message was generated when running perltidy on random text:</p>
3916
3917 <pre><code> Use of uninitialized value $K_semicolon in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 16467.</code></pre>
3918
3919 <p>This was fixed 14 Sep 2020, included in &#39;Allow line-ending &#39;=&gt;&#39; to align vertically&#39;, ea96739.</p>
3920
3921 </dd>
3922 <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>
3923 <dd>
3924
3925 <p>A rule was added to prevent a file consisting of a single semicolon</p>
3926
3927 <pre><code> ;</code></pre>
3928
3929 <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>
3930
3931 </dd>
3932 <dt id="fixed-uninitialized-value-reference2"><b>fixed uninitialized value reference</b></dt>
3933 <dd>
3934
3935 <p>The following message was generated when running perltidy on random text:</p>
3936
3937 <pre><code> Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 11926.
3938  Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 11936.
3939  Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 11944.</code></pre>
3940
3941 <p>This was fixed 13 Sep 2020 in &#39;fixed unitialized variable problem &#39;, adb2096.</p>
3942
3943 </dd>
3944 <dt id="fixed-uninitialized-value-reference3"><b>fixed uninitialized value reference</b></dt>
3945 <dd>
3946
3947 <p>The following message was generated when running perltidy on random text:</p>
3948
3949 <pre><code> substr outside of string at /home/steve/bin/Perl/Tidy/Tokenizer.pm line 7362.
3950  Use of uninitialized value in concatenation (.) or string at /home/steve/bin/Perl/Tidy/Tokenizer.pm line 7362.</code></pre>
3951
3952 <p>This was fixed 13 Sep 2020 in &#39;fixed unitialized variable problem&#39;, 5bf49a3.</p>
3953
3954 </dd>
3955 <dt id="fixed-uninitialized-value-reference4"><b>fixed uninitialized value reference</b></dt>
3956 <dd>
3957
3958 <p>The following message was generated when running perltidy on random text:</p>
3959
3960 <pre><code> Use of uninitialized value $K_opening in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 16467.</code></pre>
3961
3962 <p>This was fixed 13 Sep 2020 in &#39;fix undefined variable reference&#39;, 1919482.</p>
3963
3964 </dd>
3965 <dt id="hashbang-warning-changed"><b>hashbang warning changed</b></dt>
3966 <dd>
3967
3968 <p>The following snippet generated a warning that there might be a hash-bang after the start of the script.</p>
3969
3970 <pre><code> $x = 2;
3971  #!  sunos does not yet provide a /usr/bin/perl
3972  $script = &quot;$^X $script&quot;;</code></pre>
3973
3974 <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>
3975
3976 <p>Fixed 13 Sep 2020, &#39;prevent unnecessary hash-bang warning message&#39; 4f7733e and &#39;improved hash-bang warning filter&#39;, fa84904.</p>
3977
3978 </dd>
3979 <dt id="uninitialized-index-referenced"><b>uninitialized index referenced</b></dt>
3980 <dd>
3981
3982 <p>An unitialized index was referenced when running on a file of randomly generated text:</p>
3983
3984 <pre><code>  Use of uninitialized value $K_oo in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 7259.</code></pre>
3985
3986 <p>This was fixed 12 Sep 2020 in &#39;fixed undefined index&#39;, 616bb88.</p>
3987
3988 </dd>
3989 <dt id="Oops-message-triggered"><b>Oops message triggered</b></dt>
3990 <dd>
3991
3992 <p>The parameter combination -lp -wc triggered an internal bug message from perltidy:</p>
3993
3994 <pre><code> 398: Program bug with -lp.  seqno=77 should be 254 and i=1 should be less than max=-1
3995  713: The logfile perltidy.LOG may contain useful information
3996  713:
3997  713: Oops, you seem to have encountered a bug in perltidy.  Please check the
3998  713: BUGS file at http://perltidy.sourceforge.net.  If the problem is not
3999  713: listed there, please report it so that it can be corrected.  Include the
4000  ...</code></pre>
4001
4002 <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>
4003
4004 </dd>
4005 <dt id="Internal-fault-detected-by-perltidy"><b>Internal fault detected by perltidy</b></dt>
4006 <dd>
4007
4008 <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>
4009
4010 <pre><code>  perltidy --noadd-newlines --space-terminal-semicolon
4011
4012   if ( $_ =~ /PENCIL/ ) { $pencil_flag= 1 } ; ;
4013   $yy=1;</code></pre>
4014
4015 <p>This triggered the message:</p>
4016
4017 <pre><code> ==============================================================================
4018  While operating on input stream with name: &#39;&lt;stdin&gt;&#39;
4019  A fault was detected at line 7472 of sub &#39;Perl::Tidy::Formatter::store_token_to_go&#39;
4020  in file &#39;/home/steve/bin/Perl/Tidy/Formatter.pm&#39;
4021  which was called from line 8298 of sub &#39;Perl::Tidy::Formatter::process_line_of_CODE&#39;
4022  Message: &#39;Unexpected break in K values: 591 != 589+1&#39;
4023  This is probably an error introduced by a recent programming change.
4024  ==============================================================================</code></pre>
4025
4026 <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>
4027
4028 </dd>
4029 <dt id="Error-parsing-deprecated-variable"><b>Error parsing deprecated $# variable</b></dt>
4030 <dd>
4031
4032 <p>This problem can be illustrated with this two-line snippet:</p>
4033
4034 <pre><code>  $#
4035   eq$,?print&quot;yes\n&quot;:print&quot;no\n&quot;;</code></pre>
4036
4037 <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>
4038
4039 </dd>
4040 <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>
4041 <dd>
4042
4043 <p>This problem can be illustrated with the following test snippet which was not correctly parsed.</p>
4044
4045 <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>
4046
4047 <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>
4048
4049 <pre><code> print $$ &lt; 300  ? &quot;$$&lt;300\n&quot;
4050    : $$ &lt; 700    ? &quot;$$&lt;700\n&quot;
4051    : $$ &lt; 2_000  ? &quot;$$&lt;2,000\n&quot;
4052    : $$ &lt; 10_000 ? &quot;$$ &lt;10,000\n&quot;
4053    :               &quot;$$&gt;9,999\n&quot;;</code></pre>
4054
4055 </dd>
4056 <dt id="code-crash-with-cuddled-else-formatting-on-unbalanced-files"><b>code crash with cuddled-else formatting on unbalanced files</b></dt>
4057 <dd>
4058
4059 <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>
4060
4061 </dd>
4062 <dt id="error-message-Unterminated-angle-operator"><b>error message &#39;Unterminated angle operator?&#39;</b></dt>
4063 <dd>
4064
4065 <p>This error can be demonstrated with this line.</p>
4066
4067 <pre><code>  print $i &lt;10 ? &quot;yes&quot; : &quot;no&quot;;</code></pre>
4068
4069 <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>
4070
4071 </dd>
4072 <dt id="Line-broken-after-here-target"><b>Line broken after here target</b></dt>
4073 <dd>
4074
4075 <p>This problem is illustrated with the following snippet</p>
4076
4077 <pre><code>  $sth= $dbh-&gt;prepare (&lt;&lt;&quot;END_OF_SELECT&quot;) or die &quot;Couldn&#39;t prepare SQL&quot; ;
4078       SELECT COUNT(duration),SUM(duration)
4079       FROM logins WHERE username=&#39;$user&#39;
4080   END_OF_SELECT</code></pre>
4081
4082 <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>
4083
4084 </dd>
4085 <dt id="undefined-variable-named-test2"><b>undefined variable named &#39;test2&#39;</b></dt>
4086 <dd>
4087
4088 <p>An uninitialized value was being referenced and triggered this message:</p>
4089
4090 <pre><code> undefined test2, i_opening=5, max=18, caller=Perl::Tidy::Formatter ./perltidy-20200907.pl 13465
4091  Use of uninitialized value $test2 in numeric eq (==) at ./perltidy-20200907.pl line 19692.</code></pre>
4092
4093 <p>Fixed 8 Sep 2020 in &#39;fixed rare problem with stored index values for -lp option&#39;, 4147c8c.</p>
4094
4095 </dd>
4096 <dt id="Line-order-switched-at-start-of-quoted-text"><b>Line order switched at start of quoted text</b></dt>
4097 <dd>
4098
4099 <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>
4100
4101 <pre><code>    perltidy --line-up-parentheses --paren-vertical-tightness=1
4102
4103     if (
4104         ( $name, $chap ) =
4105         $cur_fname =~ m!^Bible/
4106           .*?/          # testament
4107           .*?/          # range of books
4108           (.*?)/        # book name
4109           .*?           # optional range of verses
4110           (\d+)$!x
4111       )
4112     {
4113         $cur_name = &quot;$name $chap&quot;;
4114     }</code></pre>
4115
4116 <p>This gave</p>
4117
4118 <pre><code>    if (( $name, $chap ) =
4119           .*?/          # testament
4120         $cur_fname =~ m!^Bible/
4121           .*?/          # range of books
4122           (.*?)/        # book name
4123           .*?           # optional range of verses
4124           (\d+)$!x
4125       )
4126     {
4127         $cur_name = &quot;$name $chap&quot;;
4128     }</code></pre>
4129
4130 <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>
4131
4132 </dd>
4133 <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>
4134 <dd>
4135
4136 <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>
4137
4138 <pre><code>    --noadd-newlines --nowant-left-space=&#39;=&#39; </code></pre>
4139
4140 </dd>
4141 <dt id="an-issue-with-the--x-flag"><b>an issue with the -x flag</b></dt>
4142 <dd>
4143
4144 <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>
4145
4146 <pre><code> print(SCRIPT$headmaybe . &lt;&lt;EOB . &lt;&lt;&#39;EOF&#39; .$tailmaybe),$!;
4147  #!$wd/perl
4148  EOB
4149  print &quot;\$^X is $^X, \$0 is $0\n&quot;;
4150  EOF</code></pre>
4151
4152 <p>The resulting file had a syntax error (here-doc target EOB changed).</p>
4153
4154 <pre><code> print(SCRIPT$headmaybe . &lt;&lt;EOB . &lt;&lt;&#39;EOF&#39; .$tailmaybe),$!;
4155  #!$wd/perl
4156  EOB print &quot;\$^X is $^X, \$0 is $0\n&quot;;
4157  EOF</code></pre>
4158
4159 <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>
4160
4161 <p>A warning was added to the manual 7 Sept 2020 in &quot;add warning about inappropriate -x flag&quot;, fe66743.</p>
4162
4163 </dd>
4164 <dt id="error-parsing-sub-signature"><b>error parsing sub signature</b></dt>
4165 <dd>
4166
4167 <p>This problem was reduced to the following snippet:</p>
4168
4169 <pre><code> substr
4170  (
4171   $#
4172  )</code></pre>
4173
4174 <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>
4175
4176 <pre><code>  $container_type =~ /^sub/;</code></pre>
4177
4178 <p>was corrected to be</p>
4179
4180 <pre><code>  $container_type =~ /^sub\b/;</code></pre>
4181
4182 </dd>
4183 <dt id="uninitialized-value-message-found-7-Sep-2020"><b>uninitialized value message, found 7 Sep 2020</b></dt>
4184 <dd>
4185
4186 <p>Unitialized values were referenced. An index was not being tested. Fixed 8 Sep 2020 in &quot;fix undefined variable&quot;, 9729965.</p>
4187
4188 <pre><code> Use of uninitialized value $Kon in array element at /home/steve/bin/Perl/Tidy/Formatter.pm line 4022.
4189  Use of uninitialized value $Kon in array element at /home/steve/bin/Perl/Tidy/Formatter.pm line 4023.
4190  Use of uninitialized value $Ko in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 4023.</code></pre>
4191
4192 </dd>
4193 </dl>
4194
4195 <h1 id="Open-Issues">Open Issues</h1>
4196
4197 <p>These are known issues which have not been fixed.</p>
4198
4199 <dl>
4200
4201 <dt id="lexical-subs-not-fully-supported"><b>lexical subs not fully supported</b></dt>
4202 <dd>
4203
4204 <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>
4205
4206 <p>First consider the following snippet</p>
4207
4208 <pre><code>  sub s {
4209     my $arg=$_[0];
4210     print &quot;s called with arg $arg\n&quot;;
4211   }
4212   s(1);
4213   s(2);</code></pre>
4214
4215 <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>
4216
4217 <p>Now consider the following snippet in which the sub has a preceding &#39;my&#39;</p>
4218
4219 <pre><code>  use feature &#39;lexical_subs&#39;, &#39;signatures&#39;;
4220   my sub s {
4221     my $arg=$_[0];
4222     print &quot;s called with arg $arg\n&quot;;
4223   }
4224   s(1);
4225   s(2);</code></pre>
4226
4227 <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>
4228
4229 <p>Another issue is that perltidy does not yet remember the extent of the scope of a lexical sub.</p>
4230
4231 </dd>
4232 <dt id="issues-with-paren-less-calls"><b>issues with paren-less calls</b></dt>
4233 <dd>
4234
4235 <p>Consider the following snippet:</p>
4236
4237 <pre><code>  use Test::More;
4238   ok open($stdin, &quot;&lt;&amp;&quot;, $1), &#39;open ... &quot;&lt;&amp;&quot;, $magical_fileno&#39;, ||  _diag $!;</code></pre>
4239
4240 <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>
4241
4242 <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>
4243
4244 <p>The problem can be avoid if parens are used:</p>
4245
4246 <pre><code>  ok ( open($stdin, &quot;&lt;&amp;&quot;, $1), &#39;open ... &quot;&lt;&amp;&quot;, $magical_fileno&#39;) ||  _diag $!;</code></pre>
4247
4248 </dd>
4249 <dt id="multiple-sub-paren-calls"><b>multiple sub paren calls</b></dt>
4250 <dd>
4251
4252 <p>Perltidy currently flags as an error a closing paren followed by an opening paren, as in the following</p>
4253
4254 <pre><code>  $subsubs[0]()(0)</code></pre>
4255
4256 <p>This syntax is ok. The example is from test &#39;current_sub.t&#39; in perl5.31.</p>
4257
4258 </dd>
4259 </dl>
4260
4261
4262 </body>
4263
4264 </html>
4265
4266