No need to generate a file when linting, as the coffeescript compiler
will do that for you.
This has been tested with coffeescript 1.6.2.
Also: use options over flags for readibility
JSHint has a secondary error format that includes a number related to the error message.
E.g. The normal error format is something like:
.\Foo.js: line 2, col 5, Missing semicolon. (W033)
But the secondary error format includes a number in parentheses:
.\Foo.js: line 3, col 4, Blocks are nested too deeply. (2) (W073)"
I've changed the errorformat to read the message until it hits a space, instead of a period, so that these errors are included.
pass `jshint` the `--verbose` option to get 'W' or 'E' indicating
whether something is a warning or an error.
NOTE: this was tested with jshint 1.1.0 installed with `npm install
jshint`
It now uses the correct path for the dart_analyzer, it uses the
machine readable format to provide more information.
The highlighter now highlights the exact span that the analyzer complains
about. Further, warnings are different from errors now.
The variable force_highlight_callback is gone.
Highlight functions are now consistently named
SyntaxCheckers_<filetype>_<checker>_GetHighlightRegex(), and they
take precedence over highlighting based on column.
RVM does not always provide an executable for specific ruby version
that is loaded (the "system" version).
RVM, or whatever else the user uses, should always setup "ruby" to point
to the correct version so this can always be used.
In today's html editing, almost nobody writes a "pure" html code
(complete, i mean), with body, title, etc... most of people uses CMS's
and similar things, which means that the html is just a "piece" of html
and not the entire structure, the changes on this branch are meant to
ignore those annoying warnings
The last line is for structures that includes the "&" character, like in
those kind of cases: < a href="http://foo.bar/something.php&value&something&foo" >
PHP mess detector expects the filename as the first argument, followed
by the output format and the rules. To fix this, use the 'post_args' to
provide the arguments.
Also change the subchecker to 'phpmd' instead of 'phpcs'.
Add 2 classes: SyntasticChecker and SyntasticRegistry.
SyntasticChecker represents a checker. It holds funcrefs to the checker
func, the highlight regex func and a new `isAvailable()` func (that
essentially just checks if the checker exe is installed)
SyntasticRegistry is responsible for:
* loading checkers
* storing checkers
* fetching the checkers to use according to availability and the users
settings
Motivation/benefits:
* in the current system only one checker can be loaded per filetype
* syntax checkers cant be "chained" together
* the system is hard to add features to since fundamental concepts like
syntax checkers and location lists arent represented explicitly
Things left to do:
* add a call to g:SyntasticRegistry.CreateAndRegisterChecker() to all
checkers
* add an `isAvailable` function to all checkers
* move all checkers into `syntax_checkers/filetype/checkername.vim` -
g:SyntasticRegistry assumes this layout, and its a good idea anyway
for consistency and it makes it easier for users to add their own
checkers
Things to do after all of the above:
* add a LocationList class and move all the filtering functions onto it
* possibly add an Error class that wraps up each item in a loc list
Random notes:
* with the new system you can select the checkers to use with e.g.
`let g:syntastic_python_checkers=['flake8', 'pylint']`
This will try flake8 first, and if no errors are detected it will move
onto pylint.
update makeprg builder:
* it now accepts `fname`, `tail`, and `post_args` params.
* add some doc above syntastic#makeprg#build
* update a bunch of checkers to use the new params
Still have quite a few checkers that arent using makeprg#build.
Including all c* and a few other c-like checkers. And PHP.
Not to worried about c* as these checkers are complicated and probably
justify having their own logic to build makeprgs.
Make all the easy updates. There are still quite a few to do, but in
doing these ones I can see that syntastic#makeprg#build() needs to
accept a few more options. Namely:
* "postargs" that appear after the filename
* "tail" that appears after everything - used for things like
redirecting output and piping to grep/sed/etc
* the filename itself - only the java checkers needed this since they
specify the directory of the file to check as well
There are still a few other things to do as well:
* remove the options from the checkers that are now provided by
syntastic#makeprg#build implicitly - i.e. the checker exe and args.
* also, we need to doc the above implicit checker options
Using the scala compiler instead of the interpreter to check the syntax
means that an error will not be raised if there is a package
decleration.
Also, stopping the compiler after the parser stage stops errors being
raised when importing from other files in your project.
The problem
---
Some people want to change the syntax checker args and/or executable.
Currently they have to create their own checker to do this.
Solution
---
Create a standard API for building a makeprg that allows users to set
global variables to override the exe or args.
This API is in use in the coffee and python/flake8 checkers - as
proofs of concept.
So, if the user wanted to change the args that get passed to `flake8`
they can now set `let g:syntastic_python_flake8_args="--foo --bar"` in
their vimrc. Similarly they could set `let
g:syntastic_python_flake8_exe='python foo.py'`
In simple case it just miss warnings:
$ echo '$a=5;' | perl syntax_checkers/efm_perl.pl -c -w -
(nothing, while it should be this:)
W:-:1:Name "main::a" used only once: possible typo
In complex cases with some other errors it show crazy warnings
in crazy line numbers.
Use case when efm_perl run on STDIN can be found in issue#261.
If the shebang contains -T, then the makeprg looks like:
perl '/path/to/efm_perl.pl' -c -w '/tmp/foo.pl' -Tc
Mods to syntastic#util#ParseMagicNumber
* rename it to ParseShebang (since this name seems more common)
* return an empty result set rather than 0 so callers dont have to
check if empty()
That way, the files are properly treated as C/C++ even when they don't
have the standard file extension
Signed-off-by: Florent Bruneau <florent.bruneau@intersec.com>
Previously we were only loading "official" checkers that had been added
to syntastic. Now we load any checker that is in the right directory.
This allows anyone to add custom checkers to any filetype that uses
`SyntasticLoadChecker()`
The advantage to this is that no 3rd party modules are required. People
new to Python probably won't have flake8/pyflakes/pylint installed. This
will get them basic syntax checking (no linting) out of the box.
Since we're only using ghc to check and lint the file and not actually create output, we can pass -fno-code which omits code generation and speeds up the check quite a bit.
* only check `executable()` for the sub checkers once - at the top of
the script
* recapitalize `s:getPHPMDErrors` to `s:GetPHPMDErrors` errors for
style consistency
* simplify the logic in `SyntaxCheckers_php_GetLocList`
If no syntax errors are found, `gofmt -l % 1>/dev/null` prints the file
name to STDOUT, which is redirected to /dev/null. Less to parse for
syntastic!
If errors are found, they are written to STDERR.
This invocation does not alter the source code, which has been indicated
in the comments.
Query RVM for the version of ruby that should be used to do the syntax
check.
This wont work if the user has different versions of ruby for different
directories (e.g. if they are using a project rvmrc) as it will only a
single ruby version per vim instance.
I think this should satisfy almost everyone though, so we can wait for
feedback before doing anything more hardcore.
The error message in 'puppet parser validate' changed between Puppet 2.x
and Puppet 3.0.0, preventing syntax errors from being caught.
In addition, the logic to apply --ignoreimport was falsely triggering on
3.0.0, because it was written assuming a major version of "2". The
--ignoreimport flag has been broken since 2.6.1, so I removed all of that
logic. In theory, it could be re-added for 2.6.0 and 0.2x.x, but the
version number checking didn't handle 0.2x.x, so I didn't reach back that
far.
