⚠️we only talk aboutCursorHold here, but the same bug also applies forCursorHoldI⚠️

• nvim --version:

NVIM v0.5.0-575-g225f0bcd9Build type: ReleaseLuaJIT 2.1.0-beta3Compilation: /usr/bin/cc -O2 -DNDEBUG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/antoine/src/neovim/build/config -I/home/antoine/src/neovim/src -I/home/antoine/src/neovim/.deps/usr/include -I/usr/include -I/home/antoine/src/neovim/build/src/nvim/auto -I/home/antoine/src/neovim/build/include

• vim -u DEFAULTS (version: ) behaves differently?vim 8.2.716 behaves differently
• Operating system/version: Debian testing up-to-date
• Terminal name/version: alacritty 0.4.3
• $TERM: alacritty

Steps to reproduce usingnvim -u NORC

nvim -u NORC

Then, sourcetest.vim where test.vim is:

setupdatetime=100autocmdCursorMoved*echom"CursorMoved"autocmdCursorHold*echom"CursorHold"function!s:timer_callback(timer_id)endfunctionletw:matchup_timer=timer_start(50,\function('s:timer_callback'),\{'repeat':-1})

Actual behaviour

neovim never echoesCursorHold, onlyCursorMoved
vim echoes bothCursorHold andCursorMoved

This seems to indicate thatneovimCursorHold autocmd can be blocked by timers, whenvim uses a differentthread to deal withCursorHold?

Note: whentimer_start's delay is greater thanupdate_time,neovim displaysCursorHold, but it seems more laggy thanvim.

Expected behaviour

I expectCursorHold execution not to depend on whethertimers are running or not.
Especially when this results in blocking it completely or making it laggy.

Also, thanks a lot for this amazing editor ❤️

Thanks,
Antoine