Previously the 2 checkers were in the same file - this is more "tidy"
(lol??).
Currently the logic to determine which checker is loaded is custom to
the checker. At some point the SyntasticLoadChecker() function should be
upgraded to be able to handle cases (like this one) where the name of
the checker doesnt imply the name(s) of the executables that have to be
checked for.
The logic for this option was reversed in 2 places. Puppet-lint should
have been getting disabled for old versions and if it wasnt installed,
but the logic was wrong.
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.
dont refer to g:syntastic_python_checker since - due to a previous
commit - this is not guaranteed to exist any more.
This change should have been done in the aforementioned commit - but I
failed.
display_errors might be turned of for php globally. In this case the
output of php -l does not contain the errors messages. Using this option
will turn the option on for the single call.
The parameter `g:syntastic_python_checker_args` can be used to pass additional
arguments to the Python syntax checker. Example configuration:
let g:syntastic_python_checker = "flake8"
let g:syntastic_python_checker_args = "--ignore=E501 --max-complexity=10"
Replace the color codes these regexes: /.\{-}/
This is needed for portability since, when using tmux, the output is not
colorized. Also, Im not sure that different terminals will
use the same codes for the colors - but Im no expert.
previously we assumed the user had efm_perl.pl installed as part of the
standard vim runtime, but this isnt so for CentOS and possibly for other
distros - see issue #159. Therefore, we now ship it with syntastic
itself.
Note: efm_perl.pl just munges the output of perl into a different
format. It may be worth investigating further and writing our own
errorformat to remove the dependency on efm_perl.
Javascript and json have multiple syntax checkers that can be loaded.
Previously the logic to determine which checker to load was basically
copied and pasted in both. The `go` checker will soon have more
than one option too so remove the duplication by sticking the
common code in the core.
running phpcs on a file which contains a parse error generates a huge
number of warnings from the phpcs library. This can freeze vim for
minutes at a time while it attempts to parse these
notices/warnings/errors.
Therefore - don't run phpcs on files which have parse errors.
* remove some unneeded escaping of spaces and colons from the 1.2
errorformat
* split the pre and post 1.2 errorformats up and comment them for future
clarity
Remove the g:syntastic_nvcc_binary option as this should be in the users
path - or at least symlinked in. Also, the logic was broken in that the
script was hardcoded to only accept '/usr/local/cuda/bin/nvcc' as the
binary anyway.
