recommend plugin:ale

[taizilongxu]

https://github.com/w0rp/ale

Asynchronous Lint Engine, it faster than any checker I have used, and the most importent is the feature of lint while you type

[wsdjeg]

Neomake is better than ale.

[wsdjeg]

You should check how many issues fixed and PR merged of these two project.

[crisidev]

I do not agree Neomake is better than Ale. Regarding PRs and issue, Ale is way more used than Neomake and I don't think this is a valid indicator of the project maturity.

SpaceVim (and neomake) live checking are very flaky, since the change is based on writing temporary files on disk and it is not actually async at all. Ale instead is truly async and you can see it with heavy linting systems like gometalinter or rustc. Vim does not flicker and linting happens as you type.

I would suggest to review the position and at least add a possibility for users to decide instead of just closing the issue.

[wsdjeg]

If you familier with neomake, you will see why it is better than ale. fly checking need to be fixed in SpaceVim. it do not use neomake feature. but I think you Can open new issue for plugin recommend. BTW, list the differences between them will be better.

[crisidev]

I used both extensively and I still think ale is worth a shot. I will open a plugin request as soon as I have time.

[crisidev]

Actually I will post a PR to allow users to use Ale if they want.

[kurojishi]

I second this heavily, after migrating to SpaceVim i did try Neomake for some months after a bit less of a year on ale.

For sure ale is younger and has less checkers available and it's less feature rich(no autofix, the api is far less powerful, it does not actually build stuff so you have to do it separately), but having neovim as a first class citizen it use the async features a lot better.

So there's a trade off here, more functionality against a faster and cleaner auto completion.
As such i think the road of given the user a choice is the better one, even more if you consider that at the moment doing it manually can be tricky.

[wsdjeg]

@kurojishi I will look into it, for async features support I think both neomake and ale are the same.

I'm confused about why people are willing to spend time making repetitive tools, as neomake already has the same characteristics, or even better features.

@blueyed would you like to comment something about the different features between ale and neomake?

[crisidev]

Neomake and Ale are doing the same job, just in a different way, like ycm and deoplete in a certain sense.

My only point is that more than one user is asking for Ale instead of Neomake and given SpaceVim aim is to be a community driven vim distribution, I would let users the choice of what to use.

@wsdjeg you said "I'm confused about why people are willing to spend time making repetitive tools, as neomake already has the same characteristics, or even better features."

This is the same for deoplete and ycm. Deoplete devel started in 2015, while ycm started in 2012. Why Shougo worked on something which is already provided by ycm? I guess because he thought ycm was not good enough for his usecase, and he did a great job delivering an amazing autocompletion system. I personally still prefer ycm thou, but the great thing about SpaceVim is that you can decide which one to use.

I think the same should be applied to Ale vs Neomake.

I have almost ready a PR to let user choose what to use. Are you willing to review and integrate my effort in SpaceVim?

[wsdjeg]

@crisidev deoplete and ycm is not same, YCM only support complete from one sources at one time, but deoplete support multi-sources, you can complete from buffer tags omni etc. at the same time. but what is the difference between ale and neomake?

[crisidev]

No, I do not agree. ycm support complete from various source, such as the buffer, tag files, comments, language identifiers, general omnifunc, filesystem path, etc.

I personally use ycm + eclim + eclipse headless for ruby completion and it is using the onmifunc coming from eclipse..

The difference between ale and neomake is this:

• Ale works better, is faster, does not make vim flicker if using lint-as-you-type, does not use temporary files for lint-as-you-type, is less heavy on resources.

I don't understand why the focus is only on differences between ale and neomake..

Regarding all my questions above, I'll repeat them:

• I have almost ready a PR to let user choose what to use. Are you willing to review and integrate my effort in SpaceVim?
• Don't you think it should be good to let uses decide what they want to use?

[blueyed]

Ale works better, is faster, does not make vim flicker if using lint-as-you-type

This might due to the integration in SpaceVim that @wsdjeg mentioned - have not checked it.

does not use temporary files for lint-as-you-type

Neomake also supports linters that have support for stdin, but this has to be enabled.
Since automaking is rather new, this is only enabled for (some) Python makers AFAIK.

On the other hand there are a lot of makers that do not support stdin, and not only because of that Neomake supports more makers out of the box.

is less heavy on resources.

In what regard?

I think having an option to chose is fine, but also the integration of Neomake should be reviewed/revisited probably.

[blueyed]

The integration is here: https://github.com/SpaceVim/SpaceVim/blob/dev/config/plugins_before/neomake.vim

This is rather bad actually - assuming that you complain about the spacevim_lint_on_the_fly mostly.

I suggest trying to not enable neomake via SpaceVim, but then configure/enable it manually according to https://github.com/neomake/neomake/#setup.
This will use timers etc, and better events than just TextChangedI.

[crisidev]

@blueyed I agree that also neomake integration should be reviewed. Thanks for the explanations over my bullets :)

Regarding resource usage, I think it could be because of the constant write of temporary file in SpaceVim implementation.

I will try to finish the PR for initial ale support and will post it.

[blueyed]

I think it is more related to not using timers.

TextChangedI happens all the time!
I would rather not suggest to react on it, but only TextChanged and InsertLeave (+ using a timer).
See #931 for some WIP - but I am not using SpaceVim myself, so this is untested.

[crisidev]

Hum... Ale and Neomake are seriously conflicting. Once Ale is installed, it can be not active, but there will be warnings because it conflicts with Neomake. I will need some time to undestand how to deal with this given I never used Dein as plugin manager..

[blueyed]

Once Ale is installed, it can be not active, but there will be warnings because it conflicts with Neomake.

Go figure.. ;)

To be honest, I would rather think that SpaceVim should not have settings on top of whatever syntax checker you might want to use, but should rather detect which one is installed when it comes to providing helpers to toggle them.

1. There are many different ways to configure it, e.g. when Neomake's automaking should be triggered, and if you want to see the location list then etc.
2. There are different ways to at least toggle Neomake (global, tab, buffer) - SpaceVim could either support all of them, or chose the most fitting one (I've gone with the global switch in WIP: improve Neomake integration #931).

This way a SpaceVim user could just add the plugin they want to use, and configure it to their liking.
SpaceVim could then look for e.g. if :NeomakeToggle and/or neomake#statusline#get exists.(btw: Neomake's statusline has also been very much improved lately, which is likely not reflected in SpaceVim).

As for SpaceVim with Neomake I would suggest to also add https://github.com/blueyed/vim-qf_resize and https://github.com/romainl/vim-qf by default - the former is broken for Vim though however IIRC.

[blueyed]

As for popularity: ALE was using lint-as-you-type from the beginning, while this has only recently been merged into Neomake. That is likely the main reason for it to be more popular.
I've put a lot of effort into handling all the corner cases with different versions of Vim and Neovim when taking over maintainership for Neomake, and often have seen issues popping up with ALE that had been fixed (with tests) in Neomake already.

I've once asked the author of ALE why he had not joined Neomake instead of creating a similar plugin, and the response was basically that every programmer is free to program what they want - and I guess that applies to users, too.. :)

To repeat, I would suggest you try Neomake how it is supposed to be used (quick hack is likely to not enable it with SpaceVim, and put e.g. call neomake#configure#automake('nrw', 1000) into your config.

[crisidev]

@blueyed I tried your solution and it actually works quite well. I have a small set of config which I deploy as a SpaceVim plugin and I added the quickfix there.

I would still like to try to add Ale, but if you and @wsdjeg think the checker layer should be revisited, it may be better to wait until you have a clear decision on the design.

[blueyed]

@crisidev
Yes, I think you should wait.
And I still think that using ALE should be as easy as Neomake, although I prefer Neomake myself.
Thanks for the feedback!

[wsdjeg]

Thanks for your suggestion, I will look into checker layer.

[crisidev]

Thanks a lot for the help and the discussion @blueyed and @wsdjeg!