From 44e0afac03b62eed08f70adbeaa761927b1342af Mon Sep 17 00:00:00 2001 From: Steve Hancock Date: Mon, 14 Dec 2020 15:52:33 -0800 Subject: [PATCH] Improved some alignments by avoiding a tree pruning step --- lib/Perl/Tidy/VerticalAligner.pm | 15 +++++++--- local-docs/BugLog.pod | 48 ++++++++++++++++++++++++++++---- 2 files changed, 53 insertions(+), 10 deletions(-) diff --git a/lib/Perl/Tidy/VerticalAligner.pm b/lib/Perl/Tidy/VerticalAligner.pm index 3d71fae4..72f86a09 100644 --- a/lib/Perl/Tidy/VerticalAligner.pm +++ b/lib/Perl/Tidy/VerticalAligner.pm @@ -2038,6 +2038,7 @@ sub sweep_left_to_right { $is_good_alignment_token{'='} = 1; $is_good_alignment_token{'if'} = 1; $is_good_alignment_token{'unless'} = 1; + $is_good_alignment_token{'=>'} = 1 # Note the hash values are set so that: # if ($is_good_alignment_token{$raw_tok}) => best @@ -3296,7 +3297,7 @@ sub get_line_token_info { } }; } ## end loop over lines - return $rline_values; + return ( $rline_values, $all_monotonic ); } sub prune_alignment_tree { @@ -3362,7 +3363,12 @@ sub prune_alignment_tree { # Note that the caller had this info but we have to redo this now because # alignment tokens may have been deleted. - my $rline_values = get_line_token_info($rlines); + my ( $rline_values, $all_monotonic ) = get_line_token_info($rlines); + + # If all the lines have levels which increase monotonically from left to + # right, then the sweep-left-to-right pass can do a better job of alignment + # than pruning, and without deleting alignments. + return if ($all_monotonic); # Contents of $rline_values # [ @@ -3770,11 +3776,12 @@ sub Dump_tree_groups { } # When the first of the two lines ends in a bare '=>' this will - # probably be marginal match. + # probably be marginal match. (For a bare =>, the next field length + # will be 2 or 3, depending on side comment) $line_ending_fat_comma = $j == $jmax_1 - 2 && $raw_tok eq '=>' - && $rfield_lengths_0->[ $j + 1 ] == 2; + && $rfield_lengths_0->[ $j + 1 ] <= 3; my $pad = $rfield_lengths_1->[$j] - $rfield_lengths_0->[$j]; if ( $j == 0 ) { diff --git a/local-docs/BugLog.pod b/local-docs/BugLog.pod index 4a36fc70..fb1be9e7 100644 --- a/local-docs/BugLog.pod +++ b/local-docs/BugLog.pod @@ -2,12 +2,48 @@ =over 4 +=item B + +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 +higher level alignments. This usually works well, but some deeper alignments +can be lost, which is what was happening in the example below. It turns out +that if the tree pruning is skipped when alignments vary monotonically across +lines, as in the example, then better alignments is achieved when a later pass +is made with the 'sweep' pass. + + # OLD + my $cmd = shift @ARGV; + if ( $cmd eq "new" ) { $force_new = 1; } + elsif ( $cmd eq "interactive" ) { $interactive = 1; $batch = 0; } + elsif ( $cmd eq "batch" ) { $batch = 1; $interactive = 0; } + elsif ( $cmd eq "use_old" ) { $use_old = 1; } + elsif ( $cmd eq "show" ) { $show = 1; last; } + elsif ( $cmd eq "showall" ) { $showall = 1; last; } + elsif ( $cmd eq "show_all" ) { $showall = 1; last; } + elsif ( $cmd eq "remove" ) { $remove = 1; last; } + elsif ( $cmd eq "help" ) { $help = 1; last; } + + # NEW + my $cmd = shift @ARGV; + if ( $cmd eq "new" ) { $force_new = 1; } + elsif ( $cmd eq "interactive" ) { $interactive = 1; $batch = 0; } + elsif ( $cmd eq "batch" ) { $batch = 1; $interactive = 0; } + elsif ( $cmd eq "use_old" ) { $use_old = 1; } + elsif ( $cmd eq "show" ) { $show = 1; last; } + elsif ( $cmd eq "showall" ) { $showall = 1; last; } + elsif ( $cmd eq "show_all" ) { $showall = 1; last; } + elsif ( $cmd eq "remove" ) { $remove = 1; last; } + elsif ( $cmd eq "help" ) { $help = 1; last; } + +This update was made 14 Dec 2020. + =item B 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, 'match_line_pairs' was added to set a flag with the -information needed to detect and prevent this. This fix was made 13 Dec 2020. +information needed to detect and prevent this. This fix was made 13 Dec 2020, 9a8e49b. # OLD $sec = $sec + ( 60 * $min ); @@ -37,15 +73,15 @@ can come out okay, but sometimes it can be very poor. For example: The second line is a continuation of the first, and this update prevents this alignment. The above 'BAD' formatting was in the previous developmental -version of perltidy, not the previous release. This update added 12 Dec 2020. +version of perltidy, not the previous release. This update added 12 Dec 2020, 5b56147. =item B 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. -Some examples: +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 @@ -78,8 +114,8 @@ of the line length limit: is( MyClass->meta, $mc, '... these metas are still the same thing' ); is( MyClass->meta->meta, $mc->meta, '... these meta-metas are the same thing' ); -In this last example, the first comma is not aligned, but space allows -alignment to resumes with the second comma. +In this last example, the first comma is not aligned, but alignment resumes +after the second comma. # OLD is( $obj->name, $COMPRESS_FILE, " Name now set to '$COMPRESS_FILE'" ); -- 2.39.5