Auto report-width specified in ruleset.xml ignored

[caipre]

I glanced through the code and I'm not sure what's wrong, but phpcs doesn't seem to respect the report-width or extensions arguments when specified via ruleset.xml.

My ruleset.xml starts like this:

<?xml version="1.0"?>
<ruleset name="MySniffs">
  <arg name="report-width" value="auto" />
  <arg name="extensions" value="php" />

   <! -- rule refs omitted -->
</ruleset>

I do see that the arguments are captured, but the report isn't as wide as it should be:

$ ~/code/codesniffer/scripts/phpcs --standard=CSNStores -vv
Processing ruleset ...
    ...
    => set command line value --report-width=auto
    => set command line value --extensions=php
    ...
FILE: /home/nick/foo/bar/baz.php
----------------------------------------------------------------------
FOUND 39 ERRORS AFFECTING 23 LINES
----------------------------------------------------------------------
...

I noticed that extensions doesn't work by observing the file counts given by the -p option when using the command line --extensions=php versus the xml <arg name="extensions" value="php">.

Any thoughts?

[gsherwood]

I can replicate the problem with auto report width. It is not currently supported because the terminal width code has already been run by the time the ruleset gets to set the width, but this should work and I'll fix it up.

I can't replicate any problems with the extensions setting though. All verbose and progress output is showing that the setting is in effect.

[gsherwood]

I've fixed the auto report-width setting for ruleset.xml files, and also noticed it was working correctly in a CodeSniffer.conf file as well, so fixed it there too.

I'll close this issue as the bit I could replicate is fixed, and there isn't a problem with setting CLI args in the ruleset in general. If you have more information to help we replicate the extensions issue, please report a new bug. Thanks for finding this one.

[caipre]

Great, thanks for fixing! I'll take another look at extensions.

[caipre]

Okay, it seems that extensions is respected, my fault.

I did notice that it causes failures when running unit tests though, unless I'm doing something wrong?

$ phpunit --filter Foo ~/code/codesniffer/tests/AllTests.php       

PHPUnit 4.5.1 by Sebastian Bergmann and contributors.                    

Configuration read from /home/nick/code/codesniffer/phpunit.xml          

EEEEEEEEE                                                                

Tests generated 0 unique error codes                                     

Time: 295 ms, Memory: 30.25Mb                                            

There were 9 errors:                                                     

1) Foo_Tests_WhiteSpace_ClassOpeningBraceUnitTest::testSniff       
Undefined index: extensions                     <------- error here

/home/nick/code/codesniffer/CodeSniffer/CLI.php:677                      
/home/nick/code/codesniffer/CodeSniffer/CLI.php:413                      
/home/nick/code/codesniffer/CodeSniffer.php:805                          
/home/nick/code/codesniffer/CodeSniffer.php:551                          
/home/nick/code/codesniffer/tests/Standards/AbstractSniffUnitTest.php:132

...

[gsherwood]

I did notice that it causes failures when running unit tests though, unless I'm doing something wrong?

I'd have to see your custom unit tests to know what is going on. None of the built-in ones are failing, and the core classes do work slightly differently when tests are running, given there is no CLI. There are ways to fake the CLI in the test though.