> Likewise, the parameter -sbt=n or --square-bracket-tightness=n controls the
> space within square brackets, as illustrated below.
>
> $width = $col[ $j + $k ] - $col[ $j ]; # -sbt=0
> $width = $col[ $j + $k ] - $col[$j]; # -sbt=1 (default)
> $width = $col[$j + $k] - $col[$j]; # -sbt=2
> Curly braces which do not contain code blocks are controlled by the
> parameter -bt=n or --brace-tightness=n.
>
> $obj->{ $parsed_sql->{ 'table' }[0] }; # -bt=0
> $obj->{ $parsed_sql->{'table'}[0] }; # -bt=1 (default)
> $obj->{$parsed_sql->{'table'}[0]}; # -bt=2
As with PR #201, I can't find any previous concensus on introducing this
and for myself, I prefer the default.
FTR I can't find anything else in .perltidyrc that I have any bones with :)
Previously the greylist plugin tried to use redis and fell back to DBM. This means that if a system already had an established DBM database, but happened to have Redis running, the existing DBM db would be abandoned for a new Redis DB. This would inevitably lead to more delays for legitimate mail, and possibly lost mail.
This adds a 'redis_server' argument which enables Redis and sets the location of the redis server; if it is not explicitly set, DBM is used instead.
If the redis server is unavailable, rather than failing to start QP, we instead fail to register the plugin.
Revert to default of -pt=1 rather than -pt=2:
> -bt,-pt,-sbt: Container tightness
> These are parameters for controlling the amount of space within containing
> parentheses, braces, and square brackets. The example below shows the effect
> of the three possible values, 0, 1, and 2, for the case of parentheses:
>
> if ( ( my $len_tab = length( $tabstr ) ) > 0 ) { # -pt=0
> if ( ( my $len_tab = length($tabstr) ) > 0 ) { # -pt=1 (default)
> if ((my $len_tab = length($tabstr)) > 0) { # -pt=2
> A value of 0 causes all parens to be padded on the inside with a space, and
> a value of 2 causes this never to happen. With a value of 1, spaces will be
> introduced if the item within is more than a single token.
The tight parens decision was made in 2005 when .perltidyrc was introduced:
2535e77293
I tried pretty hard but couldn't find any previous discussion about this
decision, I'm not quite sure who supported it, who cared about it at all,
or who knew about it at all.
What I know is that I like pt=1 better. Nobody ever gets what they want
if they don't ask :)
Destroy the AnyDBM-tied hash after untying
Google's wisdom seems to indicate that leaving the AnyDBM-tied hash around after
untying it was causing data to not flush to the DBM file... or something. At any
rate the regression test added here confirms inconsistency when using multiple
instances which is fixed by destroying the AnyDBM-tied hash after untying.
Previously, the GeoIP plugin would crash on certain missing GeoIP data.
Now it will continue to operate on whatever data it can get at.
Note that it already warns when any data it's looking for is missing.
