Accessing vim.current.window (through python-client) breaks CursorHoldI?!

[blueyed]

I have found a strange bug when using deoplete, where accessing self.vim.current.window through a Python RPC call seems to break the CursorHoldI handling?!

See Shougo/deoplete.nvim#81 for more information and a test case (based on deoplete).

I have also tried the latest python-client from Git (https://github.com/neovim/python-client/tree/6c0ec04307442dedc851873504b379f4dcdb33a0) without success.

Why might that happen?
Where can I look further to debug this?

This breaks the feature to display call signatures (g:jedi#show_call_signatures) in jedi-vim.

[blueyed]

Just calling self.vim.eval("1") seems to trigger this issue already (when used as the first statement in
https://github.com/Shougo/deoplete.nvim/blob/fed61ada642b86cf6bb70cb6914628fbe0ac902e/rplugin/python3/deoplete/__init__.py#L46).

/cc @Shougo

[tarruda]

Why might that happen?

I have recently changed how cursor hold is triggered, but I can't immediately say what's causing the issue

Where can I look further to debug this?

cursorhold is triggered in the os_inchar function when trigger_cursorhold() && !typebuf_changed(tb_change_cnt) evaluates to true, so you could start by investigating what's causing it to always evaluate to false. There's a chance that watching the did_cursorhold global variable will reveal the cause.

[blueyed]

Seems to be related to && s->ca.cmdchar != K_EVENT at

neovim/src/nvim/normal.c

Line 1108 in a03af86

if (s->ca.cmdchar != K_IGNORE && s->ca.cmdchar != K_EVENT) {

(added in e5165ba).

[blueyed]

Also commenting this line fixes it (but breaks maybe something else?):

neovim/src/nvim/edit.c

Line 613 in a03af86

did_cursorhold = true;

[tarruda]

Also commenting this line fixes it (but breaks maybe something else?):

According to the comment, cursorhold should not trigger while processing multi-key commands such as <c-v>

Seems to be related to && s->ca.cmdchar != K_EVENT at

Close, I think the line which causes the bug is this one: e5165ba#diff-ce1f54750dd541783db1cf9a24120ba8R1221

That is because the same "special key" is used for both cursorhold and other events, and we need a way to distinguish so did_cursorhold will be set to false properly. I need to think about this for a while

[Shougo]

Reproduced.
CursorHoldI autocmd is not triggered using neovim Job API....

[jakubgs]

+1 for this issue.

[blueyed]

@tarruda
Any new insights / update on this front?

It's a very subtle, but very annoying bug.