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.

[blueyed]

@tarruda
FYI, a similar issue regarding the popup menu was fixed in #4461 - in case that helps to narrow this one down.

[justinmk]

The root cause of this issue may also affect timers: #4624 (comment)

[gelguy]

Smaller vimrc to reproduce the issue by using a timer instead of rpc

set noshowmode
set updatetime=100

let s:init = 0

function! F()
  if !s:init
    call timer_start(0, {-> 1})
  endif
  let s:init = 1
endfunction

augroup test
  au CursorHoldI * echom 'CHI'
  au InsertEnter * call F()
augroup END

Refer to

neovim/src/nvim/edit.c

Lines 643 to 644 in c6cd608

	// Don't want K_EVENT with cursorhold for the second key, e.g., after CTRL-V.
	did_cursorhold = true;

K_EVENT prevents CursorHold events from triggering. If this is changed to

  if (key != K_EVENT) {
    did_cursorhold = true;
  }

the above vimrc will work as expected.

What I'm worried about is the comment about K_EVENT... I'm not well-versed enough in that area of code to understand the implications of changing the code here.

[blueyed]

@gelguy
Thanks for this. I hope to look into this during the next week.

[blueyed]

Actually with the above vimrc from @gelguy you can also see it without a timer already: it is not triggered while staying in insert mode, inserting something, and then waiting..?!
Added the above patch to #3758.

I agree with @tarruda that this should likely be refactored / fixed properly by adding this to the state, and using a timer instead - OTOH the timeout in os_inchar is the updatetime already, so it kind of makes sense to handle it right there, in case of reading nothing because of a timeout.