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.
