The jslint guys have changed their error format again. Update the syntax
checker to handle it.
Currently jslint outputs a "use strict" error if a function doesnt have
'use strict' at the top. This is not good for our purposes, so just
filter this out for now.
The js syntax checker was 4 checkers stuffed into 1 file. Now it is
broken down so that each checker is in its own file inside
syntax_checkers/javascript/ while syntax_checkers/javascript.vim just
determines which file to source.
Change the names of the global js checker config variables so that
they all start with "syntastic_javascript_". This is purely for
namespacing.
Remove some unneeded logic around the config variables too. Not sure how
it got in there, but it was more confusing than helpful without offering
any benefits...
I installed the latest version of lessc and they have modified their
output slightly. Update the errorformat for this.
Also, they new output is colorized by default. So I have added an option
to specify args to the checker that currently defaults to "--no-color".
This means that if people want to use an older version of lessc, they
will need to reset this option to an empty string.
Many of the syntax checkers were setting the 'bufnr' key for each
error manually and one was setting 'text' if it didnt exist too.
Add the 'defaults' option to SyntasticMake to set default values in the
returned error list - it only sets values if they are empty.
PHPCS has a wide variety of commandline flags, including
support for various syntaxes. These must be configurable,
otherwise phpcs generates a high number of spurious errors for
code written to any standard other than the PEAR standard.
Previously, if we edited a new bash script then we would have to wipeout
the buffer and recreate it to get syntastic to recognise it as a bash
script. This is because it parsed out a magic number and cached that -
and it trivially fails to find a magic number when you create a new
file.
So recheck for a magic number if it is currently empty.
Also, do a small refactor.
This was missing errors like this:
/tmp/foo.js:1:(-002) Error parsing file at token ")". Unable to check the rest of file.
The reason is because of the minus sign in front of the 002. It is using
%m to match that, which appears to only match positive numbers - so just
ignore the minus sign.
This is in response to #88 where errors like this were getting missed:
SyntaxError: In simpleMapComponent.js.coffee, Reserved word "function" on line 10
at SyntaxError (unknown source)
at Lexer.identifierError (/usr/lib/node_modules/coffee-script/lib/lexer.js:458:13)
at Lexer.identifierToken (/usr/lib/node_modules/coffee-script/lib/lexer.js:80:16)
at Lexer.tokenize (/usr/lib/node_modules/coffee-script/lib/lexer.js:31:19)
at Object.compile (/usr/lib/node_modules/coffee-script/lib/coffee-script.js:29:34)
at /usr/lib/node_modules/coffee-script/lib/command.js:149:33
at /usr/lib/node_modules/coffee-script/lib/command.js:115:26
at [object Object].<anonymous> (fs.js:107:5)
at [object Object].emit (events.js:61:17)
at afterRead (fs.js:878:12)
To fix this I have added another error matcher on the front of the
errorformat and have made a fix to the %-G matcher on the end (i.e. it
wasnt actually matching anything before).
The errorformat may need more updating.
We dont need to manually hack the bufnr for each entry in the loc list
since that the error output includes a file name.
Ignore the last line of the error message since it seems to always just
be "use --trace for a backtrace"
