> > I now have a minimal reproduction of this, outside of `govim`. > > > > Key finding is that this "hang" is triggered by the channel-based > > complete function synchronously calling back into Vim before it (the > > complete function) returns. > > > > The reproduction files can be found in the following gist: > > > > https://gist.github.com/myitcv/f968c2f9f073121675ca44699d42fae4 > > > > Requires a working Go installation: https://golang.org/dl/ > > > > Run with: > > > > ``` > > $ vi -u complete.vim > > ``` > > > > Then: > > > > * enter insert mode (`i`) > > * type `mai` > > * trigger omni-complete via `<C-x><C-o>` - this should leave the first line > > reading `main` > > * still in insert mode, hit backspace to remove the `n` - this should leave > > the first line reading `mai` > > * still in insert mode, hit backspace to remove the `i` - this should leave > > the first line reading `ma` > > > > Notice at this point that Vim has hung, and will continue to hang until the > > 30 sec channel timeout is triggered. > > > > See my resulting `/tmp/vim_channel.log` here: > > https://gist.github.com/myitcv/2c9644def065e80a4ce3ba155778690c > > I'm trying to understand what happens exactly. It seems that the > response to message 9 is dropped instead of handled: > > This must result from the ch_evalexpr() call: > 2.868934 SEND on 0(in): '[9,{"Comment":"Complete > findstart","Calls":[["redraw",""]],"Delay":"100ms"}] > > And it gets back the response about 100 msec later: > 2.969833 RECV on 0(out): '[9,""] > > But then: > 2.969884 on 0: Getting JSON message 9 > 2.969893 on 0: Dropping message 9 without callback > > It appears channel_read_json_block() is used recursively, and then > ch_block_id is overwritten. This function was never written to handle a > recursive call. > > This happens because you made your server send a "redraw" while Vim is > in channel_read_json_block(), and this redraw triggers invoking listener > callbacks, which then does another ch_evalexpr(). > > I suppose the solution is to make channel_read_json_block() work > resursively. You could work around it by avoiding ch_evalexpr() in the > listener callback, use an asynchronous ch_sendexpr() and another callback. > > Making a test for this is very tricky, since it is so timing sensitive. > Thus I'll just fix the problem, and let you verify it.
Patch 8.1.1512 hopefully fixes the problem. -- hundred-and-one symptoms of being an internet addict: 138. You develop a liking for cold coffee. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/201906091818.x59IIuTt003071%40masaka.moolenaar.net. For more options, visit https://groups.google.com/d/optout.
