How can I prevent PerlTidy from aligning assignments but keep adding single spaces?

Question

How can I prevent PerlTidy from aligning assignments but keep adding single spaces?

This question is similar to How can I prevent PerlTidy from aligning my assignments? but I would like single spaces to be added where directed. Due to this -naws switch does not work for me. I just do not want multiple spaces to be inserted. Is it possibe with perltidy or some other tool?

Perl tidy changes:

my $a    = 1;
my $aa = 2;
my $aaa= 3;

into

my $a   = 1;
my $aa  = 2;
my $aaa = 3;

with -naws it remains unchanged:

my $a    = 1;
my $aa = 2;
my $aaa= 3;

I would like this code to be formatted as:

my $a = 1;
my $aa = 2;
my $aaa = 3;

Answer 1

The following patch worked for me:

--- Tidy.pm.org 2009-06-16 22:00:50.000000000 +0200
+++ Tidy.pm 2010-12-28 09:43:19.625000000 +0100
@@ -12404,7 +12404,7 @@
         # accept vertical alignment.

         # nothing to do if we aren't allowed to change whitespace
-        if ( !$rOpts_add_whitespace ) {
+        if ( 1 || !$rOpts_add_whitespace ) {
             for my $i ( 0 .. $max_index_to_go ) {
                 $matching_token_to_go[$i] = '';
             }

Answer 2

There is an undocumented flag --no-valign which appears to achieve the best of both worlds without modifying the perltidy source.

As you point out, --no-add-whitespace is too aggressive and prevents whitespace from being added in other, desirable locations (around operators etc.). With --no-valign perltidy is still correcting things like my ($arg)=@_; to my ($arg) = @_; but does not attempt to vertically align operators across lines. The setting does not completely disable the vertical aligner, so you still get some benefits in other places (e.g. side-comments).

The only problem I have found with this so far is that the first side-comment of a block of side-comments is not aligned with the subsequent ones:

my @DISAGREE_NONFATAL = grep { exists $warnings::Offsets{$_} } (
    'newline', # stat on nonexistent file with a newline in it
    'experimental', # no reason for these to be fatal
    'deprecated',   # unfortunately can't make these fatal
    'portable',     # everything worked fine here, just may not elsewhere
);

It is only respecting --minimum-space-to-comment. I'm not sure why the subsequent (third and fourth) lines work properly. I don't use side-comments much so it's not a major issue (and you could use --format-skipping on such blocks).