inverse search hangs when some vim process is stuck

[user202729]

(this is just to track the issue since it doesn't seem particularly fixable at the moment. Although one possible "fix" is to spawn one vim subprocess per server (expensive), or set timeout = 1 (I don't know if there is any side effect, but 1 second is still a long time))

Description

Sometimes, inverse search will hang because of https://github.com/vim/vim/issues/15843 . It's a better idea to be robust against that.

Steps to reproduce

1. Create a hanging vim process as described in the linked issue

   [~]$ vim &
   [1] 1124625
   [~]$ jobs
   [1]+  Stopped                 vim
   [~]$ 
   

2. create a normal vim process, and somehow make sure its v:servername appears later than the hanging process in serverlist()

3. try inverse search e.g.

   vim -v --not-a-term -T dumb -c "VimtexInverseSearch 100:-1 'file.tex'" 
   

4. see that the first remote_expr() call is stuck and vimtex never gets to try sending to the second process (actually after 600 seconds)

Expected behavior

somehow vimtex should just ignore the erroneous state of the first process and proceed to send to the second process?

[lervag]

Thanks. This seems like a relatively rare and particularly edgy edge case. But it is also well described and reproducible.

I would expect that 1 second timeout should be more than enough, and as you say, even if it will still feel strange, it may be a viable workaround here?

[user202729]

Up to you. Another possibility is to just wait for vim to implement async remote_expr or something… hopefully soon. Waiting also has a slight advantage of not having to modify the code again to remove the current "hacky workaround" later.

(anecdote: this happens to me in real life once because of a vim process hanging… I've no idea what started the process in the first place because the parent presumably got killed. On the positive side, this doesn't have a compounding effect because somehow a vim process hanging waiting for remote_expr itself can respond to other processes' remote_expr — that is, if vim1 hangs, vim2 is waiting for remote_expr("vim1"), then vim3 can evaluate remote_expr("vim2") successfully in parallel.)

(unrelated question: what do you do for a living? you seem to be very active here somehow)

[lervag]

Up to you. Another possibility is to just wait for vim to implement async remote_expr or something… hopefully soon. Waiting also has a slight advantage of not having to modify the code again to remove the current "hacky workaround" later.

Ok, yes, if you don't mind, then waiting seems like a good option. Please feel free to notify me when an async version is available in case I miss it.

(unrelated question: what do you do for a living? you seem to be very active here somehow)

Previously I was a research scientist, today I'm a software engineer. I am quite active, especially at answering issues. It's hard to get the time to do lengthy code improvement and new features these days, though.