Search code, repositories, users, issues, pull requests...

Owner

I will inspect it. Do you have any clue to reproduce it ? Could you see the "[Finished in xxx seconds]" in the quickfix window when vim got stuck ?

Owner

Does ":AsyncStop!" help (AsyncStop with a "!" ) ?

Owner

The latest MacVim includes only 8.0.124.
How can you use 8.0.134 ??

junkblocker

Author

I am not doing anything special. I have a command run on every document save. After a while the problem appears. It is possible that at some point MacVim stopped responding to input and I had to Ctrl+C a few times it which got it unstuck but that maybe prevents some state cleanup. No I don't see the message in quickfix window.

I built MacVim myself applying patches from upstream also (all scripted away). So usually have newer versions that officially available MacVim build. BTW, if you build directly from head, it is at 134 already as of a few days ago ( https://github.com/macvim-dev/macvim/commits/master ) without any manual patching needed.

I'll try AsyncStop! next time the problem appears.

I have this same problem and it's starting to make me a little crazy. I use this plugin to run a build script so that I can quickly compile the code I'm editing. I just updated the plugin today and the frequency of the jobs getting stuck has gone up.

I tried AsyncStop! and it doesn't help, nor does AsyncStop.

My build command is: nnoremap <leader>b :AsyncRun! -save=2 ./build*<cr> with build* being some shell script that kicks off a MSVC process. I see the [Finished in X seconds] message and a success status. I don't know how to consistently recreate the bug though. It just seems to randomly happen and I have to close vim to get it working again.

I'm using vim 8.0 with patches 1-606 on Windows 7. I built it myself.

I also have another command that sometimes triggers this bug:

function! HideAsyncResults()
  call asyncrun#quickfix_toggle(g:build_window_size, 0)
endfunction

function! SilentBuild()
  AsyncStop
  exec "AsyncRun! -save=2 -post=call\\ HideAsyncResults() ./build*"
endfunction

nnoremap <F8> :call SilentBuild()<cr>

I wonder if the -save=2 flag is the culprit. I'm going to remove it for a bit and see if that helps.
UPDATE: still experiencing this when I remove -save=2

I noticed that if I get into the stuck state and then try to reload my vimrc using so $MYVIMRC I get this error: Error detected while processing function AsyncRun_Job_OnTimer[11]..<SNR>51_AsyncRun_Job_Update:

Followed by these two errors repeatedly until I close vim

E716: Key not present in Dictionary: raw == 1
E15: Invalid expression: s:async_info.raw == 1

Owner

don't press ctrl-c

don't press ctrl-c

Can you please be more specific? I don't recall pressing ctrl-c at any point when experiencing the stuck job state I described above.

@skywind3000 I have the same issue on Ubuntu16.04, vim 8.0.14.18 (complied today).
The issue happens only if the command is executed super fast.

For instance, the following command works fine and can be repeated as many time as I want:
:AsyncRun sleep 1; echo foo

However, the second execution of the follwing command will trigger the error "ERROR: background job is still running":
:AsyncRun echo foo
The first execution does not print [Finished in ? seconds].
Also, AsyncStop! does not help.

Do you know what that could be ?
Thanks for the excellent plugin anyway :)

Antoine

Owner

sorry, it can't be reproduced on my debian / cygwin and mac os x.
Could you try to disable other plugins temporarily before invoking AsyncRun ?

Thanks for the quick response.
I did some investigation, here is the minimal vimrc to reproduce the bug:

call plug#begin('~/.vim/plugins_by_vimplug')
Plug 'skywind3000/asyncrun.vim'
call plug#end()
set nocompatible

autocmd BufWinEnter * call system("sleep 1")

Also, you have to add copen | to trigger the issue:
:copen | AsyncRun echo foo

Running that command will trigger autocmd system("sleep 1"), echo foo finishes first, hence the bug.

I hope this help,
Antoine

:help job says:
Note that if the job exits before you read the output, the output may be lost.
This depends on the system (on Unix this happens because closing the write end
of a pipe causes the read end to get EOF). To avoid this make the job sleep
for a short while before it exits.

@skywind3000 , do you have any news about this bug ?
Were you able to reproduce it ?