Vim 8.0

46 views
Skip to first unread message

Francisco Garcia

unread,
Sep 13, 2016, 5:49:01 AM9/13/16
to vim-syntastic
Vim 8 is out with official support for asynchronous plugins.

Is there any conversation / issue / roadmap about Syntastic taking advantage of that feature?

I understand that migrating current plugins is a long and hard work, but I am more curious if an alternative, second way to write plugins so they are async will be added

-- Francisco

LCD 47

unread,
Sep 13, 2016, 6:31:26 AM9/13/16
to vim-syntastic
On 13 September 2016, Francisco Garcia <fga...@zenbits.io> wrote:
> Vim 8 is out with official support for asynchronous plugins.
>
> Is there any conversation / issue / roadmap about Syntastic taking
> advantage of that feature?

Async checking is planned. There is currently no conversation
about it (other than me mumbling to myself once in a while), presumably
because people who care about that have already migrated to Neomake.

> I understand that migrating current plugins is a long and hard work,

It isn't that much work. The hard part about it is getting the
design right.

> but I am more curious if an alternative, second way to write plugins
> so they are async will be added

The current plan is to make as many changes as possible without
affecting functionality, then release a 3.8.0 to get those tested. That
would be the final release without async checking. A 4.0-pre branch
will be opened simultaneously, that would change the internal API. When
the async checking functionality is ready, a 4.0 will be released.

Release 4.0 will still be able to run old checkers. Async checkers
will be identified by the presence of two new functions, one that would
submit a job for checking, and another (optional) that would process
the results after getting them back from the linter. Checkers without
these two functions will be run synchronously. A majority of checkers
will probably be migrated before the 4.0 release, but there will still
be some left for people to test (I don't have a working setup for _all_
those things), and a minority will probably have to stay synchronous.

I hope this answers your question.

/lcd

gasp...@gmail.com

unread,
Oct 6, 2016, 5:30:46 AM10/6/16
to vim-syntastic
I'll jump in your thread ;)

I patched syntastic to have also on-fly checks without saving file - so you see hint check while existing insert mode or on CursorHold.
Now changes are not compatible with current version again )

I see that big update is coming, so should I wait until async functionality appears in syntastic and try to merge it to new version or it is worth to try to merge it to current HEAD?

You can check out my version here - https://github.com/gasparch/syntastic/tree/onfly_syntax_check

if you set  g:syntastic_check_on_esc = 1 it will run linter (only jshint/vim) also when you made changes and did not done actions in editor for some time.

Works very nicely for me for last 1.5-2 years, as it gives much faster error detection and also I can have running test watcher which does not break immediately because of wrong syntax.

Any thoughts/comments ?

/Gaspar


LCD 47

unread,
Oct 6, 2016, 5:55:13 AM10/6/16
to vim-syntastic
On 6 October 2016, <gasp...@gmail.com> wrote:
> I'll jump in your thread ;)

On a side note: you hijacked this thread for no reason. Your
message has nothing to do with the initial one.

> I patched syntastic to have also on-fly checks without saving file -
> so you see hint check while existing insert mode or on CursorHold.
> Now changes are not compatible with current version again )

This has been discussed on the issue tracker in the past. It has
been rejected, because it doesn't make sense for about a third of the
existing checkers. For example try making it work for rst/sphinx to get
an idea what could go wrong.

> I see that big update is coming, so should I wait until async
> functionality appears in syntastic and try to merge it to new version
> or it is worth to try to merge it to current HEAD?
[...]

As I said, it won't work for all checkers. For this reason, I'll
never consider merging it to syntastic.

On the other hand, if you want to maintain this as a fork, it's up
to you to decide what to backport from the official syntastic. Things
will break in the near future.

/lcd

gasp...@gmail.com

unread,
Oct 25, 2016, 9:07:32 AM10/25/16
to vim-syntastic


On Thursday, October 6, 2016 at 12:55:13 PM UTC+3, LCD 47 wrote:
On 6 October 2016, <gasp...@gmail.com> wrote:
> I'll jump in your thread ;)

    On a side note: you hijacked this thread for no reason.  Your
message has nothing to do with the initial one.

Async support can help greatly for on-fly checks, that's why I asked here.
 

> I patched syntastic to have also on-fly checks without saving file -
> so you see hint check while existing insert mode or on CursorHold.
> Now changes are not compatible with current version again )

    This has been discussed on the issue tracker in the past.  It has
been rejected, because it doesn't make sense for about a third of the
existing checkers.  For example try making it work for rst/sphinx to get
an idea what could go wrong.


I implemented it on per checker basis, right now I have it on-fly only for JS.
 
> I see that big update is coming, so should I wait until async
> functionality appears in syntastic and try to merge it to new version
> or it is worth to try to merge it to current HEAD?
[...]

    As I said, it won't work for all checkers.  For this reason, I'll
never consider merging it to syntastic.


So, if you will not consider it if it is just option, that specific checker can turn on to provide that functionality?
 
    On the other hand, if you want to maintain this as a fork, it's up
to you to decide what to backport from the official syntastic.  Things
will break in the near future.


Ok, thanks.
 
/Gaspar

LCD 47

unread,
Oct 25, 2016, 9:29:03 AM10/25/16
to vim-syntastic
On 25 October 2016, <gasp...@gmail.com> wrote:
> On Thursday, October 6, 2016 at 12:55:13 PM UTC+3, LCD 47 wrote:
[...]
> >
> > As I said, it won't work for all checkers. For this reason,
> > I'll never consider merging it to syntastic.
> >
> >
> So, if you will not consider it if it is just option, that specific
> checker can turn on to provide that functionality?
[...]

Not in syntastic. The point of syntastic is to provide a general
framework for checking. There are many language-specific plugins that
have a lot more features than syntastic, for their target languages.
Syntastic doesn't try to compete with them. Going there would make
syntastic unmaintainable at best. Which is why checker-specific options
and to be kept at an absolute minimum, and features that stand no chance
to work for 2/3 of the already supported checkers are out of question.

Still, like I said, nothing stops you from forking syntastic and
making it suit your needs.

/lcd

gasp...@gmail.com

unread,
Oct 25, 2016, 1:55:10 PM10/25/16
to vim-syntastic

    Not in syntastic.  The point of syntastic is to provide a general
framework for checking.  There are many language-specific plugins that
have a lot more features than syntastic, for their target languages.
Syntastic doesn't try to compete with them.  Going there would make
syntastic unmaintainable at best.  Which is why checker-specific options
and to be kept at an absolute minimum, and features that stand no chance
to work for 2/3 of the already supported checkers are out of question.

    Still, like I said, nothing stops you from forking syntastic and
making it suit your needs.


Thank you !
 
    /lcd
Reply all
Reply to author
Forward
0 new messages