The location list returned by getloclist() may contain entries that are
not errorformat matches. By "definition", (see :help getqflist), matched
lines have the attribute "valid": 1 set, so only keep those lines in
error/warning list to avoid erroneous counts and strange behaviors.
Signed-off-by: Florent Bruneau <florent.bruneau@intersec.com>
The output of flake8 is ambiguous as to whether results should be
interpreted as warnings or errors. I have changed it to assume errors to
match the python/pyflakes checker.
In future we may want to change this or add items to the errorformat for
some specific warnings if they are annoying.
This fixes#203.
setting it to E_PARSE causes some errors to be missed - e.g.
`$a[$b][] $c;`
will not cause an error to get reported as this is classed as a compile
error, not a parse error.
This should fix#206.
This is needed to handle compound filetypes since we cant imply the
location of the syntax checker file from the filetype.
e.g. we want to load `syntax_checkers/python/pylint.vim`, but the
filetype is `python.django`. Previously this was causing `runtime
syntax_checkers/python.django/pylint.vim` to be executed.
* move the existing ruby checker to syntax_checkers/ruby/mri.vim
* add a skeleton checker for jruby
* load mri by default but add an option to specify which ruby checker to
load
This is in response to #185
* remove the public SyntasticHighlightErrors() function
* shift the above code into s:HighlightErrors(). This is called
automatically if g:syntastic_enable_highlighting is set
* to get the highlight regex we just look for a function called
Syntastic_<filetype>_GetHighlightRegex
* to force this function to be called, each error item must have the
'force_highlight_callback' key set
This code has one important functional change: now errors are *always*
highlighted if possible whereas previously they were only highlighted if
a call to SyntasticHighlightErrors was made.
The error messages that pyflakes outputs dont contain enough information
to classify them as errors or warnings. Apart from checking for all
known warning outputs and classifying the rest as errors (or vice versa)
there is no way classify.
Make the syntax checker class all results as errors. Individual warning
formats can be checked for later if they become a problem.
This addresses #189.
