403

<?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<link rev="made" href="mailto:root@localhost" />
</head>

<body>

<ul id="index">
 <li><a href="#Issues-fixed-after-release-20201207">Issues fixed after release 20201207</a></li>
 <li><a href="#Issues-fixed-after-release-20201202">Issues fixed after release 20201202</a></li>
 <li><a href="#Issues-fixed-after-release-20201001">Issues fixed after release 20201001</a></li>
 <li><a href="#Issues-fixed-after-release-20200907">Issues fixed after release 20200907</a></li>
 <li><a href="#Open-Issues">Open Issues</a></li>
</ul>

<h1 id="Issues-fixed-after-release-20201207">Issues fixed after release 20201207</h1>

<dl>

<dt id="Improve-indentation-of-multiline-qw-quotes-when--xci-flag-is-set">Improve indentation of multiline qw quotes when -xci flag is set</dt>
<dd>

The indentation of multiline qw quotes runs into problems when there is nesting, as in the following.

<pre><code> # OLD: perltidy -xci -ci=4
 for my $feep (
 qw{
 pwage pwchange pwclass pwcomment
 pwexpire pwgecos pwpasswd pwquota
 }
 )</code></pre>

The problem is that multiline qw quotes do not get the same indentation treatment as lists.

This update fixes this in the following circumstances:

<pre><code> - the leading qw( and trailing ) are on separate lines
 - the closing token is one of ) } ] &gt;
 - the -xci flag is set</code></pre>

The above example becomes

<pre><code> # NEW: perltidy -xci -ci=4
 for my $feep (
 qw{
 pwage pwchange pwclass pwcomment
 pwexpire pwgecos pwpasswd pwquota
 }
 )</code></pre>

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

<pre><code> # OLD and NEW: perltidy -wn -xci -ci=4
 for my $feep ( qw{
 pwage pwchange pwclass pwcomment
 pwexpire pwgecos pwpasswd pwquota
 } )</code></pre>

This update added 8 Jan 2021, 474cfa8.

</dd>
<dt id="Improve-alignment-of-leading-equals-in-rare-situation">Improve alignment of leading equals in rare situation</dt>
<dd>

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.

<pre><code> # OLD:
 $them = &#39;localhost&#39; unless ( $them = shift );
 $cmd = &#39;!print&#39; unless ( $cmd = shift );
 $port = 2345 unless ( $port = shift );
 $saddr = &#39;S n a4 x8&#39;;
 $SIG{&#39;INT&#39;} = &#39;dokill&#39;;

# NEW
 $them = &#39;localhost&#39; unless ( $them = shift );
 $cmd = &#39;!print&#39; unless ( $cmd = shift );
 $port = 2345 unless ( $port = shift );
 $saddr = &#39;S n a4 x8&#39;;
 $SIG{&#39;INT&#39;} = &#39;dokill&#39;;</code></pre>

Fixed 5 Jan 2021, 9244678.

</dd>
<dt id="Moved-previous-patch-to-a-better-location">Moved previous patch to a better location</dt>
<dd>

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.

</dd>
<dt id="Further-improvement-in-rules-for-forgetting-last-side-comment-location">Further improvement in rules for forgetting last side comment location</dt>
<dd>

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:

<pre><code> OLD: perltidy -sct -act=2
 foreach $line (
 [0, 1, 2], [3, 4, 5], [6, 7, 8], # rows
 [0, 3, 6], [1, 4, 7], [2, 5, 8], # columns
 [0, 4, 8], [2, 4, 6]) # diagonals

NEW: perltidy -sct -act=2
 foreach $line (
 [0, 1, 2], [3, 4, 5], [6, 7, 8], # rows
 [0, 3, 6], [1, 4, 7], [2, 5, 8], # columns
 [0, 4, 8], [2, 4, 6]) # diagonals</code></pre>

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.

</dd>
<dt id="Improve-rule-for-forgetting-last-side-comment-location">Improve rule for forgetting last side comment location</dt>
<dd>

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 noticable 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:

<pre><code> # OLD:
 foreach my $r (@$array) {
 $Dat{Data}{ uc $r-&gt;[0] } = join( &quot;;&quot;, @$r ); # store all info
 my $name = $Dat{GivenName}{ uc $r-&gt;[0] } || $r-&gt;[1];

# pass array as ad-hoc string, mark missing values
 $Dat{Data}{ uc $r-&gt;[0] } = join(
 &quot;;&quot;,
 (
 uc $r-&gt;[0], uc $name, # symbol, name
 $r-&gt;[2], $r-&gt;[3], $r-&gt;[4], # price, date, time
 $r-&gt;[5], $r-&gt;[6], # change, %change
 $r-&gt;[7], &quot;-&quot;, &quot;-&quot;, &quot;-&quot;, # vol, avg vol, bid,ask
 $r-&gt;[8], $r-&gt;[9], # previous, open
 &quot;$r-&gt;[10] - $r-&gt;[11]&quot;, $r-&gt;[12], # day range,year range,
 &quot;-&quot;, &quot;-&quot;, &quot;-&quot;, &quot;-&quot;, &quot;-&quot;
 )
 ); # eps,p/e,div,yld,cap
 }</code></pre>

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:

<pre><code> # NEW:
 foreach my $r (@$array) {
 $Dat{Data}{ uc $r-&gt;[0] } = join( &quot;;&quot;, @$r ); # store all info
 my $name = $Dat{GivenName}{ uc $r-&gt;[0] } || $r-&gt;[1];

# pass array as ad-hoc string, mark missing values
 $Dat{Data}{ uc $r-&gt;[0] } = join(
 &quot;;&quot;,
 (
 uc $r-&gt;[0], uc $name, # symbol, name
 $r-&gt;[2], $r-&gt;[3], $r-&gt;[4], # price, date, time
 $r-&gt;[5], $r-&gt;[6], # change, %change
 $r-&gt;[7], &quot;-&quot;, &quot;-&quot;, &quot;-&quot;, # vol, avg vol, bid,ask
 $r-&gt;[8], $r-&gt;[9], # previous, open
 &quot;$r-&gt;[10] - $r-&gt;[11]&quot;, $r-&gt;[12], # day range,year range,
 &quot;-&quot;, &quot;-&quot;, &quot;-&quot;, &quot;-&quot;, &quot;-&quot;
 )
 ); # eps,p/e,div,yld,cap
 }</code></pre>

The following exampel shows an unexpected alignment in the cascade of trailing comments which are aligned but slowly separating from their closing containers:

<pre><code> # OLD:
 {
 $a = [
 Cascade =&gt; $menu_cb,
 -menuitems =&gt; [
 [ Checkbutton =&gt; &#39;Oil checked&#39;, -variable =&gt; \$OIL ],
 [
 Button =&gt; &#39;See current values&#39;,
 -command =&gt; [
 \&amp;see_vars, $TOP,

], # end see_vars
 ], # end button
 ], # end checkbutton menuitems
 ]; # end checkbuttons cascade
 }</code></pre>

This was caused by forgetting side comments only across code block changes. The new result is more reasonable:

<pre><code> # NEW:
 {
 $a = [
 Cascade =&gt; $menu_cb,
 -menuitems =&gt; [
 [ Checkbutton =&gt; &#39;Oil checked&#39;, -variable =&gt; \$OIL ],
 [
 Button =&gt; &#39;See current values&#39;,
 -command =&gt; [
 \&amp;see_vars, $TOP,

], # end see_vars
 ], # end button
 ], # end checkbutton menuitems
 ]; # end checkbuttons cascade
 }</code></pre>

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.

</dd>
<dt id="Fixed-very-minor-inconsistency-in-redefining-lists-after-prune-step">Fixed very minor inconsistency in redefining lists after prune step</dt>
<dd>

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.

<pre><code> # OLD
 return join( &#39;&#39;,
 $pre, &#39;&lt;IMG &#39;, $iconsizes{$alt} || &#39;&#39;,
 $align, &#39;BORDER=&#39;, $nav_border,
 &#39; ALT=&quot;&#39;, $alt, &quot;\&quot;\n&quot;,
 &#39; SRC=&quot;&#39;, $ICONSERVER, &quot;/$icon&quot;,
 &#39;&quot;&gt;&#39; );

# NEW
 return join( &#39;&#39;,
 $pre, &#39;&lt;IMG &#39;, $iconsizes{$alt} || &#39;&#39;,
 $align, &#39;BORDER=&#39;, $nav_border,
 &#39; ALT=&quot;&#39;, $alt, &quot;\&quot;\n&quot;,
 &#39; SRC=&quot;&#39;, $ICONSERVER, &quot;/$icon&quot;,
 &#39;&quot;&gt;&#39; );</code></pre>

</dd>
<dt id="Improved-vertical-alignment-of-some-edge-cases">Improved vertical alignment of some edge cases</dt>
<dd>

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:

<pre><code> # OLD:
 @gg_3 = (
 [
 0.0, 1.360755E-2, 9.569446E-4, 9.569446E-4,
 1.043498E-3, 1.043498E-3
 ],
 [
 9.569446E-4, 9.569446E-4, 0.0, 7.065964E-5,
 1.422811E-4, 1.422811E-4
 ],
 ...
 );

# NEW:
 @gg_3 = (
 [
 0.0, 1.360755E-2, 9.569446E-4, 9.569446E-4,
 1.043498E-3, 1.043498E-3
 ],
 [
 9.569446E-4, 9.569446E-4, 0.0, 7.065964E-5,
 1.422811E-4, 1.422811E-4
 ],
 ...
 );</code></pre>

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.

</dd>
<dt id="Avoid--lp-style-formatting-of-lists-containing-multiline-qw-quotes">Avoid -lp style formatting of lists containing multiline qw quotes</dt>
<dd>

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,

<pre><code> # OLD, perltidy -gnu
 @EXPORT = (
 qw(
 i Re Im rho theta arg
 sqrt log ln
 log10 logn cbrt root
 cplx cplxe
 ),
 @trig,
 );

# NEW, perltidy -gnu
 @EXPORT = (
 qw(
 i Re Im rho theta arg
 sqrt log ln
 log10 logn cbrt root
 cplx cplxe
 ),
 @trig,
 );</code></pre>

27-Dec-2020, 948c9bd.

</dd>
<dt id="improve-formatting-of-multiline-qw">improve formatting of multiline qw</dt>
<dd>

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:

<pre><code> # OLD, perltidy -wn
 # qw line
 if ( $pos == 0 ) {
 @return = grep( /^$word/,
 sort qw(
 ! a b d h i m o q r u autobundle clean
 make test install force reload look
 ) ); #&lt;-- outdented more than &#39;sort&#39;
 }

# Here is the same with a list instead of a qw; note how the
    # closing sort paren does not outdent more than the &#39;sort&#39; line.
    # This is the desired result for qw.
    # perltidy -wn
    if ( $pos == 0 ) {
        @return = grep( /^$word/,
            sort (

&#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;,
                &#39;autobundle&#39;, &#39;clean&#39;,
                &#39;make&#39;,       &#39;test&#39;, &#39;install&#39;, &#39;force&#39;, &#39;reload&#39;, &#39;look&#39;
            ) );  #&lt;-- not outdented more than &#39;sort&#39;
    }

# NEW (perltidy -wn)
 if ( $pos == 0 ) {
 @return = grep( /^$word/,
 sort qw(
 ! a b d h i m o q r u autobundle clean
 make test install force reload look
 ) ); #&lt;-- not outdented more than sort
 }</code></pre>

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

<pre><code> Class::XYZ::Overload
 ); #&lt;-- outdented more than the line with &#39;for qw(&#39;

# NEW:
    $_-&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

Class::XYZ::Overload
 ); #&lt;-- outdented same as the line with &#39;for qw(&#39;</code></pre>

26 Dec 2020, cdbf0e4.

</dd>
<dt id="improve-list-marking-method">improve list marking method</dt>
<dd>

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:

<pre><code> # OLD
 return (
 $startpos, $ldelpos - $startpos, # PREFIX
 $ldelpos, 1, # OPENING BRACKET
 $ldelpos + 1, $endpos - $ldelpos - 2, # CONTENTS
 $endpos - 1, 1, # CLOSING BRACKET
 $endpos, length($$textref) - $endpos, # REMAINDER
 );

# NEW
 return (
 $startpos, $ldelpos - $startpos, # PREFIX
 $ldelpos, 1, # OPENING BRACKET
 $ldelpos + 1, $endpos - $ldelpos - 2, # CONTENTS
 $endpos - 1, 1, # CLOSING BRACKET
 $endpos, length($$textref) - $endpos, # REMAINDER
 );</code></pre>

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)

<pre><code> # OLD: (undesirable alignment)
 my ( $isig2, $chisq ) = ( 1 / ( $sig * $sig ), 0 );
 my ( $ym, $al, $cov, $bet, $olda, $ochisq, $di, $pivt, $info ) =
 map { null } ( 0 .. 8 );

# NEW: (no alignment)
 my ( $isig2, $chisq ) = ( 1 / ( $sig * $sig ), 0 );
 my ( $ym, $al, $cov, $bet, $olda, $ochisq, $di, $pivt, $info ) =
 map { null } ( 0 .. 8 );</code></pre>

This update was made 22 Dec 2020, 36d4c35.

</dd>
<dt id="Fix-git-51-closing-quote-pattern-delimiters-not-following--cti-flag-settings">Fix git #51, closing quote pattern delimiters not following -cti flag settings</dt>
<dd>

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:

<pre><code> # OLD:
 @EXPORT = (
 qw(
 i Re Im rho theta arg
 sqrt log ln
 log10 logn cbrt root
 cplx cplxe
 ),
 @trig
 );

# NEW
 @EXPORT = (
 qw(
 i Re Im rho theta arg
 sqrt log ln
 log10 logn cbrt root
 cplx cplxe
 ),
 @trig
 );</code></pre>

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):

<pre><code> @EXPORT = (
 qw&lt;
 i Re Im rho theta arg
 sqrt log ln
 log10 logn cbrt root
 cplx cplxe
 &gt;,
 @trig
 );</code></pre>

but (&#39;;&#39; remains indented):

<pre><code> @EXPORT = (
 qw;
 i Re Im rho theta arg
 sqrt log ln
 log10 logn cbrt root
 cplx cplxe
 ;,
 @trig
 );</code></pre>

This update was added 18 Dec 2020 and modified 24 Dec 2020, 538688f.

</dd>
<dt id="Update-manual-pages-regarding-issue-git-50">Update manual pages regarding issue git #50</dt>
<dd>

Additional wording was added to the man pages regarding situations in which perltidy does not change whitespace. This update was added 17 Dec 2020.

</dd>
<dt id="Rewrote-sub-check_match">Rewrote sub check_match</dt>
<dd>

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.

<pre><code> # OLD:
 @tests = (
 @common, &#39;$_&#39;,
 &#39;&quot;\$_&quot;&#39;, &#39;@_&#39;,
 &#39;&quot;\@_&quot;&#39;, &#39;??N&#39;,
 &#39;&quot;??N&quot;&#39;, chr 256,
 &#39;&quot;\x{100}&quot;&#39;, chr 65536,
 &#39;&quot;\x{10000}&quot;&#39;, ord &#39;N&#39; == 78 ? ( chr 11, &#39;&quot;\013&quot;&#39; ) : ()
 );

# NEW:
 @tests = (
 @common, &#39;$_&#39;,
 &#39;&quot;\$_&quot;&#39;, &#39;@_&#39;,
 &#39;&quot;\@_&quot;&#39;, &#39;??N&#39;,
 &#39;&quot;??N&quot;&#39;, chr 256,
 &#39;&quot;\x{100}&quot;&#39;, chr 65536,
 &#39;&quot;\x{10000}&quot;&#39;, ord &#39;N&#39; == 78 ? ( chr 11, &#39;&quot;\013&quot;&#39; ) : ()
 );</code></pre>

</dd>
<dt id="Improved-vertical-alignments-by-avoiding-pruning-step">Improved vertical alignments by avoiding pruning step</dt>
<dd>

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.

<pre><code> # OLD
 my $cmd = shift @ARGV;
 if ( $cmd eq &quot;new&quot; ) { $force_new = 1; }
 elsif ( $cmd eq &quot;interactive&quot; ) { $interactive = 1; $batch = 0; }
 elsif ( $cmd eq &quot;batch&quot; ) { $batch = 1; $interactive = 0; }
 elsif ( $cmd eq &quot;use_old&quot; ) { $use_old = 1; }
 elsif ( $cmd eq &quot;show&quot; ) { $show = 1; last; }
 elsif ( $cmd eq &quot;showall&quot; ) { $showall = 1; last; }
 elsif ( $cmd eq &quot;show_all&quot; ) { $showall = 1; last; }
 elsif ( $cmd eq &quot;remove&quot; ) { $remove = 1; last; }
 elsif ( $cmd eq &quot;help&quot; ) { $help = 1; last; }

# NEW
 my $cmd = shift @ARGV;
 if ( $cmd eq &quot;new&quot; ) { $force_new = 1; }
 elsif ( $cmd eq &quot;interactive&quot; ) { $interactive = 1; $batch = 0; }
 elsif ( $cmd eq &quot;batch&quot; ) { $batch = 1; $interactive = 0; }
 elsif ( $cmd eq &quot;use_old&quot; ) { $use_old = 1; }
 elsif ( $cmd eq &quot;show&quot; ) { $show = 1; last; }
 elsif ( $cmd eq &quot;showall&quot; ) { $showall = 1; last; }
 elsif ( $cmd eq &quot;show_all&quot; ) { $showall = 1; last; }
 elsif ( $cmd eq &quot;remove&quot; ) { $remove = 1; last; }
 elsif ( $cmd eq &quot;help&quot; ) { $help = 1; last; }</code></pre>

This update was made 14 Dec 2020, 44e0afa.

</dd>
<dt id="Improved-some-marginal-vertical-alignments">Improved some marginal vertical alignments</dt>
<dd>

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.

<pre><code> # OLD
 $sec = $sec + ( 60 * $min );
 $graphcpu[$sec] = $line;
 $secmax = $sec if ( $sec &gt; $secmax );
 $linemax = $line if ( $line &gt; $linemax );

# NEW
 $sec = $sec + ( 60 * $min );
 $graphcpu[$sec] = $line;
 $secmax = $sec if ( $sec &gt; $secmax );
 $linemax = $line if ( $line &gt; $linemax );</code></pre>

</dd>
<dt id="Do-not-align-equals-across-changes-in-continuation-indentation">Do not align equals across changes in continuation indentation</dt>
<dd>

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:

<pre><code> # BAD:
 $! = 2, die qq/$0: can&#39;t stat -${arg}&#39;s &quot;$file&quot;./
 unless $time = ( stat($file) )[$STAT_MTIME];

# FIXED:
 $! = 2, die qq/$0: can&#39;t stat -${arg}&#39;s &quot;$file&quot;./
 unless $time = ( stat($file) )[$STAT_MTIME];</code></pre>

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.

</dd>
<dt id="Improve-vertical-alignment-in-some-two-line-matches">Improve vertical alignment in some two-line matches</dt>
<dd>

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:

# In this example the side comments were limiting the matches

<pre><code> # OLD
 shift @data if @data and $data[0] =~ /Contributed\s+Perl/; # Skip header
 pop @data if @data and $data[-1] =~ /^\w/; # Skip footer, like

# NEW
 shift @data if @data and $data[0] =~ /Contributed\s+Perl/; # Skip header
 pop @data if @data and $data[-1] =~ /^\w/; # Skip footer, like</code></pre>

# The same is true here.

<pre><code> # OLD
 if ($tvg::o_span) { $tvg::hour_span = $tvg::o_span; }
 if ( $tvg::hour_span % 2 &gt; 0 ) { $tvg::hour_span++; } # Multiple of 2

# NEW
 if ($tvg::o_span) { $tvg::hour_span = $tvg::o_span; }
 if ( $tvg::hour_span % 2 &gt; 0 ) { $tvg::hour_span++; } # Multiple of 2</code></pre>

In the next example, the first comma is now aligned but not the second, because of the line length limit:

<pre><code> # OLD
 is( MyClass-&gt;meta, $mc, &#39;... these metas are still the same thing&#39; );
 is( MyClass-&gt;meta-&gt;meta, $mc-&gt;meta, &#39;... these meta-metas are the same thing&#39; );

# NEW
 is( MyClass-&gt;meta, $mc, &#39;... these metas are still the same thing&#39; );
 is( MyClass-&gt;meta-&gt;meta, $mc-&gt;meta, &#39;... these meta-metas are the same thing&#39; );</code></pre>

In this last example, the first comma is not aligned, but alignment resumes after the second comma.

<pre><code> # OLD
 is( $obj-&gt;name, $COMPRESS_FILE, &quot; Name now set to &#39;$COMPRESS_FILE&#39;&quot; );
 is( $obj-&gt;prefix, &#39;&#39;, &quot; Prefix now empty&quot; );

# NEW
 is( $obj-&gt;name, $COMPRESS_FILE, &quot; Name now set to &#39;$COMPRESS_FILE&#39;&quot; );
 is( $obj-&gt;prefix, &#39;&#39;, &quot; Prefix now empty&quot; );</code></pre>

</dd>
<dt id="Improve-vertical-alignment-in-some-marginal-matches">Improve vertical alignment in some marginal matches</dt>
<dd>

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 significatly 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.

<pre><code> # OLD
 my @roles = $self-&gt;role_names;
 my $role_names = join &quot;|&quot;, @roles;

# NEW
    my @roles      = $self-&gt;role_names;
    my $role_names = join &quot;|&quot;, @roles;

# OLD
    $sysname .= &#39;del&#39; if $self-&gt;label =~ /deletion/;
    $sysname .= &#39;ins&#39; if $self-&gt;label =~ /insertion/;
    $sysname .= uc $self-&gt;allele_ori-&gt;seq if $self-&gt;allele_ori-&gt;seq;

# NEW
 $sysname .= &#39;del&#39; if $self-&gt;label =~ /deletion/;
 $sysname .= &#39;ins&#39; if $self-&gt;label =~ /insertion/;
 $sysname .= uc $self-&gt;allele_ori-&gt;seq if $self-&gt;allele_ori-&gt;seq;</code></pre>

</dd>
<dt id="Improve-vertical-alignment-of-lines-ending-in-fat-comma">Improve vertical alignment of lines ending in fat comma</dt>
<dd>

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.

<pre><code> # OLD
 $template-&gt;param(
 classlist =&gt; $classlist,
 ...,
 suggestion =&gt; $suggestion,
 totspent =&gt; sprintf( &quot;%.2f&quot;, $totspent ),
 totcomtd =&gt; sprintf( &quot;%.2f&quot;, $totcomtd ),
 totavail =&gt; sprintf( &quot;%.2f&quot;, $totavail ),
 nobudget =&gt; $#results == -1 ? 1 : 0,
 intranetcolorstylesheet =&gt;
 C4::Context-&gt;preference(&quot;intranetcolorstylesheet&quot;),
 ...
 );

# NEW
 $template-&gt;param(
 classlist =&gt; $classlist,
 ...,
 suggestion =&gt; $suggestion,
 totspent =&gt; sprintf( &quot;%.2f&quot;, $totspent ),
 totcomtd =&gt; sprintf( &quot;%.2f&quot;, $totcomtd ),
 totavail =&gt; sprintf( &quot;%.2f&quot;, $totavail ),
 nobudget =&gt; $#results == -1 ? 1 : 0,
 intranetcolorstylesheet =&gt;
 C4::Context-&gt;preference(&quot;intranetcolorstylesheet&quot;),
 ...
 );</code></pre>

</dd>
<dt id="Avoid-processing-a-file-more-than-once">Avoid processing a file more than once</dt>
<dd>

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

<pre><code> perltidy file1.pl file1.pl </code></pre>

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.

</dd>
<dt id="Fix-for-issue-git-49-exit-status-not-correctly-set">Fix for issue git #49, exit status not correctly set</dt>
<dd>

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.

</dd>
</dl>

<h1 id="Issues-fixed-after-release-20201202">Issues fixed after release 20201202</h1>

<dl>

<dt id="Fix-for-issue-git-47">Fix for issue git #47</dt>
<dd>

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

<pre><code> $promises[$i]-&gt;then(
 sub { $all-&gt;resolve(@_); () },
 sub {
 $results-&gt;[$i] = [@_];
 $all-&gt;reject(@$results) if --$remaining &lt;= 0;
 return ();
 }
 );</code></pre>

A bug introduced in v20201202 caused an incorrect welding to occur when the -wn flag was set

<pre><code> $promises[$i]-&gt;then( sub { $all-&gt;resolve(@_); () },
 sub {
 $results-&gt;[$i] = [@_];
 $all-&gt;reject(@$results) if --$remaining &lt;= 0;
 return ();
 } );</code></pre>

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.

</dd>
</dl>

<h1 id="Issues-fixed-after-release-20201001">Issues fixed after release 20201001</h1>

<dl>

<dt id="removed-excess-spaces-in-a-package-declaration">removed excess spaces in a package declaration</dt>
<dd>

Testing revealed that for a line such as

<pre><code> package Bob::Dog;</code></pre>

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

<pre><code> package Bob::Dog;</code></pre>

</dd>
<dt id="do-not-automatically-delete-closing-side-comments-with---indent-only">do not automatically delete closing side comments with --indent-only</dt>
<dd>

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.

</dd>
<dt id="fix-to-stop-at-1-iteration-when-using---indent-only">fix to stop at 1 iteration when using --indent-only</dt>
<dd>

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.

</dd>
<dt id="fix-for-formatting-signed-numbers-with-spaces">fix for formatting signed numbers with spaces</dt>
<dd>

In developing an improved convergence test, an issue slowing convergence was found related to signed numbers as in the following line,

<pre><code> @london = (deg2rad(- 0.5), deg2rad(90 - 51.3));</code></pre>

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

<pre><code> @london = ( deg2rad( -0.5 ), deg2rad( 90 - 51.3 ) );</code></pre>

The next time it is formatted, the &#39;-0.5&#39; counts as one token, resulting in

<pre><code> @london = ( deg2rad(-0.5), deg2rad( 90 - 51.3 ) );</code></pre>

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.

</dd>
<dt id="fix-to-prevent-conversion-of-a-block-comment-to-hanging-side-comment">fix to prevent conversion of a block comment to hanging side comment</dt>
<dd>

A rare situation was identified during testing in which a block comment could be converted to be a hanging side comment. For example:

<pre><code> sub macro_get_names { #
 #
 # %name = macro_get_names(); (key=macrohandle, value=macroname)
 #
 local (%name) = ();
 ...
 }</code></pre>

For the following specific contitions the block comment in line 2 could be converted into a hanging side comment, which is undesirable:

<pre><code> 1. The line contains nothing except for a &#39;#&#39; with no leading space
 2. It follows a line with side comment
 3. It has indentation level &gt; 0</code></pre>

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.

</dd>
<dt id="improved-convergence-test">improved convergence test</dt>
<dd>

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.

</dd>
<dt id="fixed-problem-with-vertical-alignments-involving-if-statements">fixed problem with vertical alignments involving &#39;if&#39; statements</dt>
<dd>

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

<pre><code> OLD:
 $m1 = 0;
 if ( $value =~ /\bset\b/i ) { $m0 = 1; }
 if ( $value =~ /\barithmetic/i ) { $m1 = 1; }
 if ( $m0 &amp;&amp; !$m1 ) { $CONFIG[1] = 0; }
 elsif ( !$m0 &amp;&amp; $m1 ) { $CONFIG[1] = 1; }
 else { $ok = 0; last; }

NEW:
 $m1 = 0;
 if ( $value =~ /\bset\b/i ) { $m0 = 1; }
 if ( $value =~ /\barithmetic/i ) { $m1 = 1; }
 if ( $m0 &amp;&amp; !$m1 ) { $CONFIG[1] = 0; }
 elsif ( !$m0 &amp;&amp; $m1 ) { $CONFIG[1] = 1; }
 else { $ok = 0; last; }</code></pre>

This update was made 15 Nov 2020, 2b7784d.

</dd>
<dt id="added-option--wnxl-s-to-give-control-of-welding-by-the--wn-parameter">added option -wnxl=s to give control of welding by the -wn parameter</dt>
<dd>

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.

</dd>
<dt id="merged-pull-request-git-46">merged pull request git #46</dt>
<dd>

The man page gave the incorrect string for -fse. This was fixed 11 Nov 2020 in 1f9869e.

</dd>
<dt id="recognize-overloaded-RPerl-operators-to-avoid-error-messages">recognize overloaded RPerl operators to avoid error messages</dt>
<dd>

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.

</dd>
<dt id="fix-issue-git-45--wn-and--vtc-n-now-work-together">fix issue git #45, -wn and -vtc=n now work together</dt>
<dd>

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.

</dd>
<dt id="implement-request-RT-133649-added-parameters--kbb-s-and--kba-s">implement request RT #133649, added parameters -kbb=s and -kba=s</dt>
<dd>

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.

</dd>
<dt id="added-parameters--maxue-n-and-maxle-n">added parameters -maxue=n and maxle=n</dt>
<dd>

These parameters had tentatively been hardwired in the tokenizer. Now the user can control them or turn the checks off altogether.

</dd>
<dt id="Fix-problem-parsing">Fix problem parsing &#39;$$*&#39;</dt>
<dd>

In random testing, an error was encountered parsing the following line

<pre><code> $self-&gt;{&quot;mod_id&quot;}=($$*1001)%(10**(rand()*6));
 ---^
 found Number where operator expected (previous token underlined)</code></pre>

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.

</dd>
<dt id="Update-for-git-44-fix-exit-status-for-assert-tidy-untidy">Update for git #44, fix exit status for assert-tidy/untidy</dt>
<dd>

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.

</dd>
<dt id="Fixed-problem-parsing-extruded-signature">Fixed problem parsing extruded signature</dt>
<dd>

A parsing error was encountered in a test parsing the following extruded signature:

<pre><code> sub foo2
 (
 $
 first
 ,
 $
 ,
 $
 third
 )
 {
 return
 &quot;first=$first, third=$third&quot;
 ;
 }</code></pre>

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.

The file parses correctly now, with formatted output

<pre><code> sub foo2 ( $first, $, $third ) {
 return &quot;first=$first, third=$third&quot;;
 }</code></pre>

</dd>
<dt id="Fixed-several-uses-of-undefined-variables-found-in-testing">Fixed several uses of undefined variables found in testing</dt>
<dd>

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.

</dd>
<dt id="Prevent-syntax-error-by-breaking-dashed-package-names">Prevent syntax error by breaking dashed package names</dt>
<dd>

In stress testing perltidy with the -extrude option, the following test snippet

<pre><code> use perl6-alpha;</code></pre>

was broken into sepate lines

<pre><code> use
 perl6
 -
 alpha
 ;</code></pre>

A rule was added to prevent breaking around a dash separating two barewords. Rerunning gives

<pre><code> use
 perl6-alpha
 ;</code></pre>

This was fixed 26 Oct 2020 in &#39;prevent breaking package names with trailing dashes&#39;, 9234be4.

</dd>
<dt id="Prevent-syntax-error-by-breaking-dashed-barewords">Prevent syntax error by breaking dashed barewords</dt>
<dd>

In stress testing perltidy with the -extrude option, using the following test snippet

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:

This update was added 26 Oct 2020, &#39;prevent syntax error by breaking dashed barewords&#39;, e121cae.

</dd>
<dt id="more-types-of-severe-errors-will-prevent-formatting">more types of severe errors will prevent formatting</dt>
<dd>

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

was previously output with default parameters as

along with an error message. But now it is just output verbatim as

along with an error message. This update was added 25 Oct 2020, &#39;avoid formatting files with more types of severe errors&#39;, 2a86f51.

</dd>
<dt id="added-state-as-keyword">added &#39;state&#39; as keyword</dt>
<dd>

A statement such as the following was generating an error message at the colon:

<pre><code> state $a : shared;</code></pre>

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.

</dd>
<dt id="sub-signatures-no-longer-parsed-with-prototypes">sub signatures no longer parsed with prototypes</dt>
<dd>

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:

<pre><code> # Old, input and after formatting:
 sub t123 ($list=wantarray) { $list ? &quot;list&quot; : &quot;scalar&quot; }

# New, after formatting
 sub t123 ( $list = wantarray ) { $list ? &quot;list&quot; : &quot;scalar&quot; }</code></pre>

Notice that some spaces have been introduced within the signature. Previously the contents of the parens not changed unless the parens contained a list.

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.

<pre><code> # perltidy -sal=&#39;method&#39;
 method foo4 ( $class : $bar, $bubba ) { $class-&gt;bar($bar) }</code></pre>

The &#39;:&#39; here is given a type of &#39;A&#39;. This may be used to change the spacing around it. For example:

<pre><code> # perltidy -sal=&#39;method&#39; -nwls=&#39;A&#39;
 method foo4 ( $class: $bar, $bubba ) { $class-&gt;bar($bar) }</code></pre>

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.

</dd>
<dt id="fix-parsing-problem-with">fix parsing problem with $#</dt>
<dd>

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;

This was being misparsed and was fixed 17 Oct 2020, in &#39;fixed parsing error with spaces in $#&#39; a079cdb.

</dd>
<dt id="fix-missing-line-break-for-hash-of-subs-with-signatures">fix missing line break for hash of subs with signatures</dt>
<dd>

During testing the following error was found and fixed. Given the following input snippet:

<pre><code> get(
 on_ready =&gt; sub ($worker) {
 $on_ready-&gt;end;
 return;
 },
 on_exit =&gt; sub ( $worker, $status ) { return; },
 );</code></pre>

The resulting formatting was

<pre><code> get(
 on_ready =&gt; sub ($worker) {
 $on_ready-&gt;end;
 return;
 }, on_exit =&gt; sub ( $worker, $status ) { return; },
 );</code></pre>

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 occured 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.

</dd>
<dt id="fix-issues-with-prototype-and-signature-parsing">fix issues with prototype and signature parsing</dt>
<dd>

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.

<pre><code> sub test ( # comment ))) 
 $x, $x) { $x+$y }</code></pre>

Complex signature expressions such as the following are now parsed without error:

</dd>
<dt id="improve-guess-for-pattern-or-division">improve guess for pattern or division</dt>
<dd>

The following line caused a tokenization error in which the two slashes were parsed as a pattern.

<pre><code> my $masksize = ceil( Opcode::opcodes / 8 ); # /</code></pre>

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.

</dd>
<dt id="fix--bos-to-keep-isolated-semicolon-breaks-after-block-braces">fix -bos to keep isolated semicolon breaks after block braces</dt>
<dd>

The flag -bos, or --break-at-old-semicolon-breakpoints, keeps breaks at old isolated semicolons. For example

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

</dd>
<dt id="keep-break-after-use-overload">keep break after &#39;use overload&#39;</dt>
<dd>

If a line break occurs after use overload then it will now be kept. Previously it was dropped. For example, this would be kept intact:

<pre><code> use overload
 &#39;+&#39; =&gt; sub {
 print length $_[2], &quot;\n&quot;;
 my ( $x, $y ) = _order(@_);
 Number::Roman-&gt;new( int $x + $y );
 },
 &#39;-&#39; =&gt; sub {
 my ( $x, $y ) = _order(@_);
 Number::Roman-&gt;new( int $x - $y );
 },
 ...</code></pre>

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.

</dd>
<dt id="added-flag--xci-to-improve-formatting-when--ci-and--i-are-equal-issue-git-28">added flag -xci to improve formatting when -ci and -i are equal, issue git #28</dt>
<dd>

This flag causes continuation indentation to &quot;extend&quot; deeper into structures. If you use -ci=n and -i=n with the same value of n you will probably want to set this flag. Since this is a fairly new flag, the default is -nxci to avoid disturbing existing formatting.

</dd>
<dt id="terminal-braces-not-indenting-correctly-with--bli-formatting-issue-git-40">terminal braces not indenting correctly with -bli formatting, issue git #40</dt>
<dd>

This problem is illustrated with the following snippet when run with -bli -blil=&#39;*&#39;

<pre><code> #-bli -bli list=&#39;*&#39;
 try
 {
 die;
 }
 catch
 {
 die;
 }; # &lt;-- this was not indenting</code></pre>

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.

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

<pre><code> # perltidy -bli -blil=&#39;*&#39;
 eval
 {
 my $app = App::perlbrew-&gt;new( &quot;install-patchperl&quot;, &quot;-q&quot; );
 $app-&gt;run();
 }
 or do
 {
 $error = $@;
 $produced_error = 1;
 };</code></pre>

</dd>
</dl>

<h1 id="Issues-fixed-after-release-20200907">Issues fixed after release 20200907</h1>

This is a detailed log of changes since the release 20200907. All bugs were found with the help of automated random testing.

<dl>

<dt id="Keep-any-space-between-a-bareword-and-quote">Keep any space between a bareword and quote</dt>
<dd>

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:

<pre><code> oops&quot;Your login, $Bad_Login, is not valid&quot;;</code></pre>

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.

</dd>
<dt id="Fixed-some-incorrect-indentation-disagreements-reported-in-LOG-file">Fixed some incorrect indentation disagreements reported in LOG file</dt>
<dd>

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.

</dd>
<dt id="If-an-cut-starts-a-POD-section-within-code-give-a-warning">If an =cut starts a POD section within code, give a warning</dt>
<dd>

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.

</dd>
<dt id="Switched-from-using-an-eval-block-to-the--can-function-for-sub-finish_formatting">Switched from using an eval block to the -can() function for sub finish_formatting&gt;</dt>
<dd>

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.

</dd>
<dt id="fixed-uninitialized-value-reference">fixed uninitialized value reference</dt>
<dd>

The following message was generated during automated testing

<pre><code> Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 12079.
 Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 12089.
 Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 12097.</code></pre>

The problem could be simplified to running perltidy -wn on this snippet:

<pre><code> __PACKAGE__-&gt;load_components( qw(
&gt; Core
&gt; 
&gt; ) );</code></pre>

This was fixed 20 Sep 2020 in &#39;fixed_uninitialized_value&#39;, 8d6c4ed.

</dd>
<dt id="fix-incorrect-parsing-of-certain-deprecated-empty-here-docs">fix incorrect parsing of certain deprecated empty here-docs </dt>
<dd>

The following snippet was being incorrecly parsed:

<pre><code> print &lt;&lt;
 # Hello World 13!
 
 ;
 print &quot;DONE\n&quot;;</code></pre>

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.

This was found in random testing and fixed 16 Sep 2020. A warning message about deprecated here-doc targets was added.

</dd>
<dt id="make-the-arrow-a-vertical-alignment-token-git-39">make the arrow a vertical alignment token, git #39</dt>
<dd>

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.

</dd>
<dt id="add-flags--bbhb-n--bbsb-n-bbp-n-git-38">add flags -bbhb=n, -bbsb=n, =bbp=n, git #38</dt>
<dd>

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.

</dd>
<dt id="Allow-vertical-alignment-of-line-ending-fat-comma">Allow vertical alignment of line-ending fat comma</dt>
<dd>

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.

</dd>
<dt id="fixed-uninitialized-value-reference1">fixed uninitialized value reference</dt>
<dd>

The following message was generated when running perltidy on random text:

<pre><code> Use of uninitialized value $K_semicolon in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 16467.</code></pre>

This was fixed 14 Sep 2020, included in &#39;Allow line-ending &#39;=&gt;&#39; to align vertically&#39;, ea96739.

</dd>
<dt id="Do-not-create-a-zero-size-file-by-deleting-semicolons">Do not create a zero size file by deleting semicolons</dt>
<dd>

A rule was added to prevent a file consisting of a single semicolon

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.

</dd>
<dt id="fixed-uninitialized-value-reference2">fixed uninitialized value reference</dt>
<dd>

The following message was generated when running perltidy on random text:

<pre><code> Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 11926.
 Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 11936.
 Use of uninitialized value $cti in numeric eq (==) at /home/steve/bin/Perl/Tidy/Formatter.pm line 11944.</code></pre>

This was fixed 13 Sep 2020 in &#39;fixed unitialized variable problem &#39;, adb2096.

</dd>
<dt id="fixed-uninitialized-value-reference3">fixed uninitialized value reference</dt>
<dd>

The following message was generated when running perltidy on random text:

<pre><code> substr outside of string at /home/steve/bin/Perl/Tidy/Tokenizer.pm line 7362.
 Use of uninitialized value in concatenation (.) or string at /home/steve/bin/Perl/Tidy/Tokenizer.pm line 7362.</code></pre>

This was fixed 13 Sep 2020 in &#39;fixed unitialized variable problem&#39;, 5bf49a3.

</dd>
<dt id="fixed-uninitialized-value-reference4">fixed uninitialized value reference</dt>
<dd>

The following message was generated when running perltidy on random text:

<pre><code> Use of uninitialized value $K_opening in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 16467.</code></pre>

This was fixed 13 Sep 2020 in &#39;fix undefined variable reference&#39;, 1919482.

</dd>
<dt id="hashbang-warning-changed">hashbang warning changed</dt>
<dd>

The following snippet generated a warning that there might be a hash-bang after the start of the script.

<pre><code> $x = 2;
 #! sunos does not yet provide a /usr/bin/perl
 $script = &quot;$^X $script&quot;;</code></pre>

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.

Fixed 13 Sep 2020, &#39;prevent unnecessary hash-bang warning message&#39; 4f7733e and &#39;improved hash-bang warning filter&#39;, fa84904.

</dd>
<dt id="uninitialized-index-referenced">uninitialized index referenced</dt>
<dd>

An unitialized index was referenced when running on a file of randomly generated text:

<pre><code> Use of uninitialized value $K_oo in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 7259.</code></pre>

This was fixed 12 Sep 2020 in &#39;fixed undefined index&#39;, 616bb88.

</dd>
<dt id="Oops-message-triggered">Oops message triggered</dt>
<dd>

The parameter combination -lp -wc triggered an internal bug message from perltidy:

<pre><code> 398: Program bug with -lp. seqno=77 should be 254 and i=1 should be less than max=-1
 713: The logfile perltidy.LOG may contain useful information
 713: 
 713: Oops, you seem to have encountered a bug in perltidy. Please check the
 713: BUGS file at http://perltidy.sourceforge.net. If the problem is not
 713: listed there, please report it so that it can be corrected. Include the
 ...</code></pre>

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.

</dd>
<dt id="Internal-fault-detected-by-perltidy">Internal fault detected by perltidy</dt>
<dd>

This snippet after processing with the indicated parameters triggered a Fault message in store-token-to-go due to discontinuous internal index values :

<pre><code> perltidy --noadd-newlines --space-terminal-semicolon

if ( $_ =~ /PENCIL/ ) { $pencil_flag= 1 } ; ;
 $yy=1;</code></pre>

This triggered the message:

<pre><code> ==============================================================================
 While operating on input stream with name: &#39;&lt;stdin&gt;&#39;
 A fault was detected at line 7472 of sub &#39;Perl::Tidy::Formatter::store_token_to_go&#39;
 in file &#39;/home/steve/bin/Perl/Tidy/Formatter.pm&#39;
 which was called from line 8298 of sub &#39;Perl::Tidy::Formatter::process_line_of_CODE&#39;
 Message: &#39;Unexpected break in K values: 591 != 589+1&#39;
 This is probably an error introduced by a recent programming change. 
 ==============================================================================</code></pre>

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.

</dd>
<dt id="Error-parsing-deprecated-variable">Error parsing deprecated $# variable</dt>
<dd>

This problem can be illustrated with this two-line snippet:

<pre><code> $#
 eq$,?print&quot;yes\n&quot;:print&quot;no\n&quot;;</code></pre>

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.

</dd>
<dt id="Error-message-parsing-a-file-with-angle-brackets-and-ternaries">Error message parsing a file with angle brackets and ternaries</dt>
<dd>

This problem can be illustrated with the following test snippet which was not correctly parsed.

<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>

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

<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>

</dd>
<dt id="code-crash-with-cuddled-else-formatting-on-unbalanced-files">code crash with cuddled-else formatting on unbalanced files</dt>
<dd>

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.

</dd>
<dt id="error-message-Unterminated-angle-operator">error message &#39;Unterminated angle operator?&#39;</dt>
<dd>

This error can be demonstrated with this line.

<pre><code> print $i &lt;10 ? &quot;yes&quot; : &quot;no&quot;;</code></pre>

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.

</dd>
<dt id="Line-broken-after-here-target">Line broken after here target</dt>
<dd>

This problem is illustrated with the following snippet

<pre><code> $sth= $dbh-&gt;prepare (&lt;&lt;&quot;END_OF_SELECT&quot;) or die &quot;Couldn&#39;t prepare SQL&quot; ;
 SELECT COUNT(duration),SUM(duration) 
 FROM logins WHERE username=&#39;$user&#39;
 END_OF_SELECT</code></pre>

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.

</dd>
<dt id="undefined-variable-named-test2">undefined variable named &#39;test2&#39;</dt>
<dd>

An uninitialized value was being referenced and triggered this message:

<pre><code> undefined test2, i_opening=5, max=18, caller=Perl::Tidy::Formatter ./perltidy-20200907.pl 13465
 Use of uninitialized value $test2 in numeric eq (==) at ./perltidy-20200907.pl line 19692.</code></pre>

Fixed 8 Sep 2020 in &#39;fixed rare problem with stored index values for -lp option&#39;, 4147c8c.

</dd>
<dt id="Line-order-switched-at-start-of-quoted-text">Line order switched at start of quoted text</dt>
<dd>

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:

<pre><code> perltidy --line-up-parentheses --paren-vertical-tightness=1

if (
 ( $name, $chap ) =
 $cur_fname =~ m!^Bible/
 .*?/ # testament
 .*?/ # range of books
 (.*?)/ # book name
 .*? # optional range of verses
 (\d+)$!x
 )
 {
 $cur_name = &quot;$name $chap&quot;;
 }</code></pre>

This gave

<pre><code> if (( $name, $chap ) =
 .*?/ # testament
 $cur_fname =~ m!^Bible/
 .*?/ # range of books
 (.*?)/ # book name
 .*? # optional range of verses
 (\d+)$!x
 )
 {
 $cur_name = &quot;$name $chap&quot;;
 }</code></pre>

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.

</dd>
<dt id="crash-due-to-bad-index-named-j_terminal_match">crash due to bad index named &#39;$j_terminal_match&#39;</dt>
<dd>

This crash was due to an index error which caused a non-existant 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:

<pre><code> --noadd-newlines --nowant-left-space=&#39;=&#39; </code></pre>

</dd>
<dt id="an-issue-with-the--x-flag">an issue with the -x flag</dt>
<dd>

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)

<pre><code> print(SCRIPT$headmaybe . &lt;&lt;EOB . &lt;&lt;&#39;EOF&#39; .$tailmaybe),$!;
 #!$wd/perl
 EOB
 print &quot;\$^X is $^X, \$0 is $0\n&quot;;
 EOF</code></pre>

The resulting file had a syntax error (here-doc target EOB changed).

<pre><code> print(SCRIPT$headmaybe . &lt;&lt;EOB . &lt;&lt;&#39;EOF&#39; .$tailmaybe),$!;
 #!$wd/perl
 EOB print &quot;\$^X is $^X, \$0 is $0\n&quot;;
 EOF</code></pre>

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.

A warning was added to the manual 7 Sept 2020 in &quot;add warning about inappropriate -x flag&quot;, fe66743.

</dd>
<dt id="error-parsing-sub-signature">error parsing sub signature</dt>
<dd>

This problem was reduced to the following snippet:

<pre><code> substr
 (
 $#
 )</code></pre>

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

<pre><code> $container_type =~ /^sub/;</code></pre>

was corrected to be

<pre><code> $container_type =~ /^sub\b/;</code></pre>

</dd>
<dt id="uninitialized-value-message-found-7-Sep-2020">uninitialized value message, found 7 Sep 2020</dt>
<dd>

Unitialized values were referenced. An index was not being tested. Fixed 8 Sep 2020 in &quot;fix undefined variable&quot;, 9729965.

<pre><code> Use of uninitialized value $Kon in array element at /home/steve/bin/Perl/Tidy/Formatter.pm line 4022.
 Use of uninitialized value $Kon in array element at /home/steve/bin/Perl/Tidy/Formatter.pm line 4023.
 Use of uninitialized value $Ko in subtraction (-) at /home/steve/bin/Perl/Tidy/Formatter.pm line 4023.</code></pre>

</dd>
</dl>

<h1 id="Open-Issues">Open Issues</h1>

These are known issues which have not been fixed.

<dl>

<dt id="lexical-subs-not-fully-supported">lexical subs not fully supported</dt>
<dd>

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.

First consider the following snippet

<pre><code> sub s { 
 my $arg=$_[0];
 print &quot;s called with arg $arg\n&quot;;
 }
 s(1);
 s(2);</code></pre>

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.

Now consider the following snippet in which the sub has a preceding &#39;my&#39;

<pre><code> use feature &#39;lexical_subs&#39;, &#39;signatures&#39;;
 my sub s { 
 my $arg=$_[0];
 print &quot;s called with arg $arg\n&quot;;
 }
 s(1);
 s(2);</code></pre>

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.

Another issue is that perltidy does not yet remember the extent of the scope of a lexical sub.

</dd>
<dt id="issues-with-paren-less-calls">issues with paren-less calls</dt>
<dd>

Consider the following snippet:

<pre><code> use Test::More;
 ok open($stdin, &quot;&lt;&amp;&quot;, $1), &#39;open ... &quot;&lt;&amp;&quot;, $magical_fileno&#39;, || _diag $!;</code></pre>

Note the unusual situation of a comma followed by an &#39;||&#39;. Perltidy will format this satisfactorally 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.

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.

The problem can be avoid if parens are used:

<pre><code> ok ( open($stdin, &quot;&lt;&amp;&quot;, $1), &#39;open ... &quot;&lt;&amp;&quot;, $magical_fileno&#39;) || _diag $!;</code></pre>

</dd>
<dt id="multiple-sub-paren-calls">multiple sub paren calls</dt>
<dd>

Perltidy currently flags as an error a closing paren followed by an opening paren, as in the following

<pre><code> $subsubs[0]()(0)</code></pre>

This syntax is ok. The example is from test &#39;current_sub.t&#39; in perl5.31.

</dd>
</dl>

</body>

</html>