Skip to content
This repository has been archived by the owner on Sep 20, 2023. It is now read-only.

Async make #370

Closed
wants to merge 4 commits into from
Closed

Conversation

daniel-walker
Copy link
Contributor

Makes it possible for the user to run the checkers in the background. It will only be used if the user enabled it, and the syntax checker makes use of it.

RedrawErrors. The new function takes the buffer number as an argument,
and several other functions called by RedrawErrors() are made to operate
on the specific buffer instead of the current buffer.
background. There is a new option added called "g:syntastic_async" which
turn this functionality on, but only when the syntax checker indicates
it's written to take advantage of this new functionality.

This feature depends on the AsyncCommand
plugin which can be obtained,

https://github.com/pydave/AsyncCommand
or
http://www.vim.org/scripts/script.php?script_id=3431

This code also incorporates code from Yurin Slava (aka nevar), from
https://github.com/nevar/syntastic/
task. All that needed to be done was add the "checker" dictionary value,
and add the "async_css_syntax_checker" variable.
This required the checking function to be split into two functions. One
calls SyntasticMake() and the other one does all the secondary
processing on all the error lines. Also the bufnr() had to be made into
'defaults' in SyntasticMake instead of getting set while processing
after it.
@scrooloose
Copy link
Collaborator

Hey, just so you know: I am interested in this.

I need to set aside a night to investigate it though - async stuff is scary :)

The ideal solution would be to have async totally optional (as you have here) and to have the core of the async code small and decoupled from the rest of the code. That way we can try it out for a few months and know that its easy to remove if it doesnt work out.

@kongo2002
Copy link
Collaborator

Yes, I would agree with that.
For that purpose the async code should be placed inside an autoload file (then it will be loaded on request only).

@daniel-walker
Copy link
Contributor Author

I'd say this set of patches isn't totally decoupled .. I'm not sure that all of it could be separated out, but there's for sure some parts that could be.

Something to note is that it's kind of hard to use this code .. You have to do the following,

  1. Run vim like so , "vim --servername XXXX" there XXXX is something random.
  2. Enable the async option in your .vimrc
  3. Use a syntax checked specifically modified to work with the async code.

If anything above isn't done, then it's not used. So it's not exactly trivial to use it.

@daniel-walker
Copy link
Contributor Author

The really nitty gritty of the Async stuff is inside a whole other plugin called AsyncCommand. In addition to what I mentioned above, if you don't have that additional plugging async won't enable.

@r1tch
Copy link

r1tch commented Oct 9, 2012

Note that vim --servername needs a working X server; not always the case. I am working on an async solution but it needs perfection -- VIm has zero support for async commands in general.

My idea is to start a shell command in the background with output redirected to a temporary file, then watch the file periodically (periodically means CursorMove or CursorHold autocmd events). When the process completed, parse the resulting errors in the file.

Why it's ugly: 1) needs bash for background process start; 2) continuous monitoring of a temp output file to detect completion.

@daniel-walker
Copy link
Contributor Author

I did all my testing with console vim .. So I'm not sure about the whole X server thing .. It worked find in console vim.

@bbinet
Copy link

bbinet commented Dec 3, 2012

This would be a killer feature, I would love to see this async stuff in syntastic!

@Amerzel
Copy link

Amerzel commented Jan 8, 2013

I'm also interested in this feature. It takes my perl syntax checker ~8 seconds to check.

@Thanatermesis
Copy link
Contributor

Async is a very nice feature to have, so we will not be in a "waiting state", at least something like "we can still/continue editing while its running the checker in background", but needed to wait that finishes for other less-prior tasks (save the file, exit vim, etc...)

Note: i dont know much about viml, so maybe what im saying sounds OT of viml :)

@ypresto
Copy link

ypresto commented Feb 28, 2013

+1

@brendonrapp
Copy link

This would make the syntastic user experience a lot better IMO. I hope this does not get left behind.

@np
Copy link

np commented Mar 18, 2013

+1

1 similar comment
@sdressler
Copy link

+1

@wilkerlucio
Copy link

+1

1 similar comment
@mbedna
Copy link
Contributor

mbedna commented Jun 9, 2013

+1

@molysgaard
Copy link

+1

2 similar comments
@yorickpeterse
Copy link
Contributor

👍

@Sparkboxx
Copy link

+1

@jgosmann
Copy link

jgosmann commented Aug 7, 2013

+1

The syntax checking feature of the python-mode plugin has this feature already for some time (it was introduced in commit 59d7fd7 with some fixes in the following commits). From my experience it works quite well. Maybe that code helps to implement the same feature in syntastic?

@af
Copy link

af commented Oct 18, 2013

+1, it would be awesome to have this option in syntastic!

@untaken
Copy link

untaken commented Oct 24, 2013

+1

1 similar comment
@brianpeiris
Copy link
Contributor

+1

@lcd047
Copy link
Collaborator

lcd047 commented Oct 31, 2013

Guys, please continue at #699. Do read the entire thread there before adding more +1. :)

@lcd047 lcd047 closed this Oct 31, 2013
@lucascaton
Copy link

Hi there!

Does it make sense to re-open this issue as we now have Vim 8's async I/O support?
Perhaps something similar to what neomake does?

Cheers.

@lcd047
Copy link
Collaborator

lcd047 commented Oct 19, 2016

Does it make sense to re-open this issue as we now have Vim 8's async I/O support?

No, but it would make sense for you to read the thread I mentioned above.

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

Successfully merging this pull request may close these issues.