fix(lsp): inlay hints: "Failed to delete autocmd" when closing buffer #24469

Problem:
"Failed to delete autocmd" error when deleting LspNotify autocmd. #24456

Solution:
Change a few things in the inlay_hint and diagnostic LSP code:
1. Re-introduce the `enabled` flag for the buffer state tables. Previously I was
   relying on the presence of an autocmd id in the state table to track whether
   inlay_hint / diagnostic was enabled for a buffer. There are two reasons why
   this doesn't work well:
  - Each time inlay_hint / diagnostic is enabled, we call `nvim_buf_attach` on
    the buffer, resulting in multiple `on_reload` or `on_detach` callbacks being
    registered.
  - Commands like `bwipeout` delete buffer local autocmds, sometimes before our
    `on_detach` callbacks have a chance to delete them first. This causes the
  - Use module local enabled state for diagnostic as well. bwipeout can race
    with on_detach callbacks for deleting autocmds. Error referenced in #24456.
2. Change the `LspDetach` autocmd to run each time (i.e., remove the `once`
   flag). Since we're only registering autocmds once per buffer now, we
   need to make sure that we set the enabled flag properly each time the LSP
   client detaches from the buffer.
  - Remove `once` from the LspDetach autocmds for inlay_hint and diagnostic.
    We only set up the autocmd once now. Gets removed when buffer is deleted.
3. Have the `LspNotify` handler also refresh the inlay_hint / diagnostics when
   receiving the `textDocument/didOpen` event. Before this point, the LSP
   backend doesn't have the contents of the buffer, so can't provide inlay hints
   or diagnostics.

Downsides of this approach:
* When inlay_hint / diagnostics are disabled on a buffer, it will continue to
  receive `LspNotify` events for that buffer. The callback exits early since the
  `enabled` flag is false.

Alternatives:
* Can we wrap the call to `nvim_del_autocmd` in `pcall` to swallow any errors
  resulting from trying to delete the autocmd?

Fixes #24456

Helped-by: Maria José Solano <majosolano99@gmail.com>

0 files changed, 0 insertions, 0 deletions