In issue #21, @adtac said your'e thinking about deprecating coala-vim in favor of neomake.
I opened this issue to discuss this.
The following illustrates a working example of coala+neomake, and my thoughts.
TL;DR: I think we shouldn't deprecate this plugin because moving to neomake feels like a hack.
First, here's a the base coala configuration with neomake:
let g:neomake_python_coala_maker = {
\ 'exe': '/opt/nvim/python3/bin/coala',
\ 'args': ['--bears=PyUnusedCodeBear,
\ PyCommentedCodeBear,
\ PEP8Bear,
\ PyImportSortBear,
\ PyUnusedCodeBear',
\'--no-config',
\ '--no-orig',
\ '--apply-patches',
\ '--no-color',
\ '--files']}
let g:neomake_python_enabled_makers = ['coala']
The problem with the above configuration is that vim doesn't update the buffer when coala makes changes. autoread
and checktime
don't work in this scenario because the file was changed inside vim.
To force the buffer to reload, I added a 'JobFinished' hook:
augroup neomake_hooks
au!
function! NeomakeJobFinished()
let l:jobinfo = g:neomake_hook_context.jobinfo
if l:jobinfo['maker']['name'] == "coala"
edit
endif
endfunction
autocmd User NeomakeJobFinished call NeomakeJobFinished()
autocmd BufWritePost * update | Neomake
augroup END
Now coala updates correctly, but there's a problem. neomake runs all makers in parallel, so if we add another maker that should run after coala, we're in trouble.
To solve that, we need to run each maker sequentially:
let g:neomake_python_coala_serialize = 1
but that creates another problem, because neomake stops maker processing if one of the makers returned a non-zero exit code. coala uses many non-zero status code. this forces us to add:
let g:neomake_python_coala_serialize_abort_on_error = 0
All in all, I think neomake is not the right tool to run coala.