Fixes#543.
Use `runtime!` to source all runtime files - not just the first one
found. I actually dont know how syntastic was working at all without
this...
We dont want to set the loc list by default since syntastic isnt the
only plugin using loclists - and we dont want to clobber other peoples
loclists.
This option allows the user to override this behaviour if it suits their
workflow.
Seems that `:sign define ... texthl=bar` causes `hlexists('bar')` to
return true.
So set up the highlight groups before the signs - otherwise they will
never be set up by default.
Previously we removed the code to automatically set the loclist and only
set it when required. This was needed because otherwise we could
interfere with other plugins that use the loclist.
Add the call to setloclist back in only if syntastic_auto_jump is set.
This will blow away the loclist every time the file is checked, but
setting syntastic_auto_jump is the users choice.
Fixes#533
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.
This allows users to customize the coloring of Syntastic's signs, and
also provides them a way to highlight the entire line using :sign's
linehl feature. It preserves the current default behavior of using
the error and todo highlight groups if the customized ones aren't
present. If the linehl group doesn't exist, then it's the same as not
specifying one, so no special highlighting for the line will occur.
Add CurrentFiletypes function as this logic was getting used in a couple
of places and needed a home/name - mostly because of the bizarre
substitute call that needs explanation.
Move the code to get a syntax checker by name into SyntasticRegistry
Add SyntasticLoclist class to wrap up loclists, and move loclist query
methods from syntatic.vim to the new class.
Make SyntasticChecker#getLocList() return a SyntasticLoclist.
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.
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()`
Problem: users want to define their own checking function and not use
the syntastic defaults
Solution: dont load the syntastic default if a checking function
already exists. This way users can just define their own function and
override syntastic.
e.g. the user wants to have their own ruby checker, so in their vimrc
they just add:
function! SyntaxCheckers_ruby_GetLocList()
return SyntasticMake({"some custom stuff"})
endfunction
Two different calculations were incorrectly combined in
s:OSSupportsShellpipeHack().
Introduce s:IsRedrawRequiredAfterMake() to hold the other calculation.
Closes#388
