Antoine

@tarruda @justinmk , could it be related to this comment in https://github.com/neovim/neovim/blob/master/src/nvim/os/input.c#L95 ? > // TODO(tarruda): Cursorhold should be implemented as a timer set during the > // `state_check` callback...

@Shougo do you know how Vim handles that differently?

@Shougo , you said: > I don't recommend to use CursorHold events for neovim. this is a bummer as a bunch of popular plugins rely heavily on ```CursorHold```, for instance:...

@Shougo , @tarruda , @mroavi , @lambdalisue , FYI, here is the proof that a ```CursorHold``` using timers would fix the performance issues: I used a User autocomand starting a...

@tjdevries , this would fix the scenario where ```CursorHold``` is **blocked**. However, in the case where ```CursorHold``` is not blocked, just **slow**, this would trigger all the ```CursorHold``` autocmd twice...

Here is a temporary plugin to fix this bug: https://github.com/antoinemadec/FixCursorHold.nvim - fixes slowdowns and untriggered events - add ```g:cursorhold_updatetime``` variable to leave ```updatetime``` untouched (and avoid unnecessary swap writes) The...

@erw7 , could we add this in the 0.5 milestones, or is it too much of a complex bug to be fixed in the 0.5 version?

@comfortablynick the issue appears when a plugin uses a recurring timer ```start_timer(...,{repeat: -1)}```. The closer the delay is to your "updatetime" the more likely you are to notice slowdowns on...

@tjdevries did you get a chance to take a look at it ? :pray: :raised_hands:

@clason @erw7 do you think we could add this in the 0.7 milestone or the backlog ?