Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecating coala-vim in favor of neomake #26

Open
odedlaz opened this issue Jan 31, 2017 · 2 comments
Open

Deprecating coala-vim in favor of neomake #26

odedlaz opened this issue Jan 31, 2017 · 2 comments

Comments

@odedlaz
Copy link

odedlaz commented Jan 31, 2017

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.

@sils
Copy link
Member

sils commented Mar 13, 2017

@odedlaz do you know alternatives? Sorry for not picking this up for so long. @RohanVB wanna chip in about ☝️ March 13, 2017 3:19 PM ? Pros? Cons? We should definitely decide something and give our users something.

@RohanVB
Copy link
Member

RohanVB commented Mar 13, 2017

The other option is syntastic which was mentioned.
Continuing the rest of the discussion on syntastic in #28

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants