search

kosayoda / nvim-lightbulb

VSCode 💡 for neovim's built-in LSP.
MIT License
801 stars 30 forks source link

Mitigation/changed in the light of neovim core developer's advice on avoiding CursorHold, CursorHoldI autocommands? #36

Closed krishnakumarg1984 closed 1 year ago

krishnakumarg1984 commented 2 years ago

Hi, one of the core developers of neovim has posted on the official discourse channel with the advice PSA: don’t rely on CursorHold (yet). I quote it verbatim below:

CursorHold (the following also applies to CursorHoldI) is an autocommand that is triggered when a user does not press a key for the time specified by updatetime. CursorHold has an extreme footgun, in that if there are any pending timers (created via timer_start()) CursorHold will not trigger at update time because there are pending events (created by timer_start), and the internals of CursorHold dictate that it not fire if there are pending events. If you are a plugin author, you should not rely on the behavior of CursorHold until this is fixed.

What are the implications of this info for this plugin? I think we use this particular autocommand for triggering the code action sign display, right?

kosayoda commented 2 years ago

Hello, thank you for bringing this up.

  1. Users of this plugin are not restricted to using the CursorHold or CursorHoldI events, and could technically set it up any way they wanted including having it only update on a keypress. However, that would defeat the purpose of this plugin, as without auto-updates there is no point to displaying a code action hint.
  2. I use the FixCursorHold.nvim plugin to solve the linked issue. Let me know if you know a better way to work around the current bug with CursorHold. As far as I can tell, there is no suitable replacement in Neovim. Meanwhile, I'll add to the README strongly recommending the use of the CursorHold fix plugin.