Ale: Lessons Learned from Syntastic

[lfilho]

Hey there, @w0rp thanks for your work on this.
I just read this thread: https://github.com/scrooloose/syntastic/issues/699 and it is VERY INFORMATIVE on the limitations vim has and how far can Syntastic go. He mentions the flaws that they only found out later and etc and still many plugin developers commit the same errors.

So I thought you would like to know those (in case you don't already)...

Cheers

[w0rp]

Thanks! I'll look into it. I avoided most of the issues mentioned by totally forgoing makeprg and errorformat from the start.

There is some talk saying this on the fly checking can't be done but... I've already done it. The only limitations lie in individual programs for linting not accepting stdin. Any linter worth its weight ought to be able to read from stdin.

[w0rp]

I'll close this issue, as there's nothing to really work on here, but I'll keep the information linked in mind. Thanks for the information. :+1:

[bounceme]

Hey, here is the general approach not depending on stdin. https://gist.github.com/bounceme/a2cb5c341af1b33c48689f64c678235f

I doubt it will ever be integrated into neomake but it proves the concept

[blueyed]

Just for information and referencev there is https://github.com/dojoteef/neomake-autolint by now, a Neomake plugin for longing through a temporary buffer.

[w0rp]

Always good to have more attempts at solving the same problems.

[blueyed]

Well, I tend to disagree nowadays, and think that with all the work put into Neomake/ALE/etc Syntastic (and/or vim-dispatch) would have all the missing features (async, autolint) by now. As for Neomake, it started as a proof-of-concept, when Neovim/async was still fresh - but there are far too many different linter frameworks IMHO by now, and I'd rather like to see forces being joined.

[w0rp]

Developers can really develop whatever they want. It's good to see new approaches to the same issues. The users will decide what becomes popular or not.