Syntastic: Recent commits cause errors on Neovim 0.1.5

[duckpuppy]

I updated this plugin (git told me I got 4 new commits, which are ec8d6de, 557b52f, 3925e83, and 0bedeb9 according togit log.

On neovim 0.1.5 in OSX I get the errors below. The example below is on VimEnter, but anything that calls UpdateErrors will produce the same result (like writing the file). I do not see these errors using vim 0.74. Both neovim and vim are installed via Homebrew.

Error detected while processing function <SNR>117_VimEnterHook[14]..<SNR>117_UpdateErrors[41]..341:
line   10:
E731: using Dictionary as a String
Error detected while processing function <SNR>117_VimEnterHook[14]..<SNR>117_UpdateErrors:
line   41:
E171: Missing :endif
Error detected while processing function <SNR>117_VimEnterHook:
line   14:
E171: Missing :endif

[lcd047]

Neovim is not supported. Meaning, syntastic "should work", but please don't bother reporting problems that you can't reproduce with plain Vim. I'm not using Neovim, I don't plan to change that in the foreseeable future, and I have no way to fix problems that manifest themselves only on Neovim.

As for your error message above, it really makes no sense from the point of view of Vim. Perhaps report that to Neovim developers?

[still-dreaming-1]

I'm having the same problem. It's probably not a good idea to tell people not to report things like this. Their report was already helpful for me to confirm this is an issue other people are having and it quickly pointed to it being a Neovim vs Vim issue. Another reason it is not a good idea to tell people not to report things is we might offer pull requests to fix it, but it might start out as an issue in case we find out there is a simpler way of addressing the issue. I'm not saying you have to support Neovim, but other users might help each other here. Having Neovim people use your plugin will be an ongoing thing you have to put up with because Neovim is advertised as a drop in replacement for Vim, and usually this is the case.

[still-dreaming-1]

I can confirm this is only happening in Neovim, not in Vim. Commit 557b52fb206e0151f057326f5a8b3574298ea43b introduced the issue.

[jamessan]

Is there a reason why the check for the extra argument to setloclist is being performed with a try/catch rather than using a version check (e.g., if has('patch-7.4.2200') or if v:version >= 705 || v:version == 704 && has('patch2200'), depending on whether Syntastic requires Vim >= 7.4.237)? This would work for both Neovim and Vim.

The reason the current check is failing in Neovim is because Neovim merged one of the early versions of the setloclist patch where the extra argument was just the title for the list. As it got hashed out on vim-dev, that changed to using a dictionary for the extra argument.

[lcd047]

Is there a reason why the check for the extra argument to setloclist is being performed with a try/catch rather than using a version check

@jamessan The try version is marginally more efficient, and it doesn't require me to know the exact version when the feature I need was added. In this particular case I happen to know the said version, but who cares.

The reason the current check is failing in Neovim is because Neovim merged one of the early versions of the setloclist patch where the extra argument was just the title for the list. As it got hashed out on vim-dev, that changed to using a dictionary for the extra argument.

Then I could allow E731 along with E118 and do nothing if any of them are caught, or I could try to use steloclist(..., title) as an alternative if setting it with a dictionary fails. The latter is not a good option though, since this is work in progress and I'll soon need a corresponding getloclist(0, title), which Neovim doesn't have. So it has to be the former. Commit 9981797.

That said, you guys are probably wasting your time here. I'm trying to clean up syntastic for async checks, and there will be many more changes like this. I plan to use this plugin to get around the API differences between Vim and Neovim, but that may or may not be enough, and things will have to get worse before they can get better. And I can't promise they'll get better from the point of vie of Neovim. I can only promise they'll definitely get a lot worse in the short term. So perhaps consider using Neomake in the mean time...

[jamessan]

@lcd047 Thanks for the quick fix (no pun intended) for the setloclist handling. I appreciate your willingness to take fixes for Neovim even though it's not your primary target.

We'll work things out on the Neovim side to resolve some of these API incompatibilities. We're lagging on merging Vim patches. Catching up on those will help.

[lcd047]

@jamessan Having watched Vim's development for a while, it seems to me many (most?) API incompatibilities come from a NIH syndrome on Vim's side. However, being aware of this doesn't fix anything.

[jamessan]

Well, in this case I think it's that Neovim was too eager to change the API of an existing Vim function without letting things settle on the Vim side. Granted, it took another 9 months for that to settle out, but it would have prevented this problem.