vim/syntastic
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
58ba8d3161
syntastic/syntax_checkers/python/pyflakes.vim

47 lines
2.0 KiB
VimL
Raw Normal View History

split python checker out into 3 files previously there were 3 checkers in the one file
2012-02-20 05:20:48 -05:00
"============================================================================
"File: pyflakes.vim
"Description: Syntax checking plugin for syntastic.vim
"Authors: Martin Grenfell <martin.grenfell@gmail.com>
" kstep <me@kstep.me>
" Parantapa Bhattacharya <parantapa@gmail.com>
"
"============================================================================
refactor how we represent and store checkers using python as a demo 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.
2013-01-23 19:01:30 -05:00
function! SyntaxCheckers_python_pyflakes_IsAvailable()
return executable('pyflakes')
endfunction
function! SyntaxCheckers_python_pyflakes_GetHighlightRegex(i)
split python checker out into 3 files previously there were 3 checkers in the one file
2012-02-20 05:20:48 -05:00
if match(a:i['text'], 'is assigned to but never used') > -1
\ || match(a:i['text'], 'imported but unused') > -1
\ || match(a:i['text'], 'undefined name') > -1
\ || match(a:i['text'], 'redefinition of') > -1
\ || match(a:i['text'], 'referenced before assignment') > -1
\ || match(a:i['text'], 'duplicate argument') > -1
\ || match(a:i['text'], 'after other statements') > -1
\ || match(a:i['text'], 'shadowed by loop variable') > -1
let term = split(a:i['text'], "'", 1)[1]
return '\V\<'.term.'\>'
endif
return ''
endfunction
refactor how we represent and store checkers using python as a demo 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.
2013-01-23 19:01:30 -05:00
function! SyntaxCheckers_python_pyflakes_GetLocList()
update checkers to use the new syntastic#makeprg#build() 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
2013-01-20 06:07:05 -05:00
let makeprg = syntastic#makeprg#build({
\ 'exe': 'pyflakes',
\ 'args': g:syntastic_python_checker_args,
\ 'subchecker': 'pyflakes' })
python/pyflakes: report errors by default 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.
2012-02-28 10:13:46 -05:00
let errorformat = '%E%f:%l: could not compile,%-Z%p^,%E%f:%l:%c: %m,%E%f:%l: %m,%-G%.%#'
split python checker out into 3 files previously there were 3 checkers in the one file
2012-02-20 05:20:48 -05:00
refactor how we represent and store checkers using python as a demo 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.
2013-01-23 19:01:30 -05:00
return SyntasticMake({ 'makeprg': makeprg,
\ 'errorformat': errorformat,
\ 'defaults': {'text': "Syntax error"} })
split python checker out into 3 files previously there were 3 checkers in the one file
2012-02-20 05:20:48 -05:00
endfunction
refactor how we represent and store checkers using python as a demo 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.
2013-01-23 19:01:30 -05:00
call g:SyntasticRegistry.CreateAndRegisterChecker({
\ 'loclistFunc': function('SyntaxCheckers_python_pyflakes_GetLocList'),
\ 'highlightRegexFunc': function('SyntaxCheckers_python_pyflakes_GetHighlightRegex'),
\ 'filetype': 'python',
\ 'name': 'pyflakes',
\ 'isAvailableFunc': function('SyntaxCheckers_python_pyflakes_IsAvailable')} )
Reference in New Issue Copy Permalink