> Thanks for the response. I haven't tried via terminal window, that sounds > like a good idea to investigate. > > The reason I think feedback() is innocent here is that there are other > tests as well that fails, that aren't using feedkeys() at all. I did find > one of them that is fairly small where we basically just open a file, move > the cursor and delete two lines: > vim ex 'e main.go' > vim ex 'call cursor(9,1)' > vim ex 'normal 2dd' > > The commands are sent via a channel and executed on the vim side inside a > callback handler > (https://github.com/govim/govim/blob/3dce913d76ea92ddd2e6a43fad8aebb72284f9c4/plugin/govim.vim#L262-L276). > > A interesting thing that I did find while debugging is that simply adding a > sleep to channel_read_block_json() (where the new coded was added in > v8.2.4699) changes the behaviour so that the tests pass: > @@ -3999,8 +3999,10 @@ channel_read_json_block( > > // channel_parse_messages() may fill the queue with new data to > // process. > - if (channel_has_readahead(channel, part)) > + if (channel_has_readahead(channel, part)) { > + do_sleep(200L, FALSE); > continue; > + }
Perhaps what happens is that there is readahead, but it's not sufficient to parse more. Then we busy-loop here. What we could do is get the length of the typeahed (or better: a hash) and if it's the same as last time, ignore it. > Since we do have a bunch different tests that started to fail I would > really like to understand what is going on, might very well be that > v8.2.4699 uncovered something we are doing wrong at our side. > I also captured two channel logs, one where it fails and the other that > pass (with > sleep): https://gist.github.com/leitzler/c66e9a1b181e15516ff73cfdff530a14. > The interesting part is at the end of broken.log where I manually kill the > test at 115.17, but vim still remains running at 100% CPU afterwards: > > 0.944675 RECV on 0(sock): '[0,[85,"ex","normal 2dd"]] > ' > 0.944682 : looking for messages on channels > 0.944694 on 0: Getting JSON message 0 > 0.944699 on 0: Invoking channel callback <SNR>17_define > 0.944770 : SafeState: reset: ins_typebuf() > 0.944858 SEND on 0(sock): '[97,["callback",85,[""]]] > ' > 0.944923 SEND on 0(sock): > '[98,["function","function:GOVIM_internal_BufChanged",[1,9,11,-2,[{"lnum":9,"col":1,"added":-2,"end":11,"lines":[]}]]]] > ' > 0.944936 on 0: Blocking read JSON for id 98 > 0.944941 : looking for messages on channels > 0.944945 on 0: Waiting for up to 30000 msec > 0.945009 RECV on 0(sock): '[96,["",""]] > ' > 0.945017 : looking for messages on channels > 115.174200 : raw terminal output: "^[[24;1H^[[m^[[0m" It says waiting for 30 sec, but there appears to be a gap of 115 sec. -- Over the years, I've developed my sense of deja vu so acutely that now I can remember things that *have* happened before ... /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ 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/20220426092300.9C1631C04EA%40moolenaar.net.
