You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When renaming or moving files/directories, neo-tree used to change the
name of renamed buffers while retaining the same buffer numbers. It did
not delete the old buffers and open new ones for editing.
This ended up crashing Neovim in the following scenario:
* a `BufWritePre` autocmd was created to call
`vim.lsp.buf.format({ async = false })`
* there was an LSP client registered for the buffer
* the buffer was opened and then put in the background (e.g. by
`:Neotree position=current`)
* the file was renamed/moved in neo-tree
The operation that caused the Neovim crash was the `silent! write!` that
neo-tree executes on the buffer right after it is renamed. During that
write, synchronous formatting is attempted in the `BufWritePre` autocmd.
My assumption is that the LSP server does not get a notification about
the file rename and sends some invalid formatting information back to
Neovim. Neovim cannot interpret it and crashes.
The crash does not happen if the renamed buffer is currently visible,
rather than being hidden (e.g. when the renamed buffer is in one window
and neo-tree is opened in a vertical split).
The approach to handling file renamed used in this commit is the same as
used in the `vim.lsp.util.rename` [0]. Instead of reusing the buffers in
Neovim before and after rename, neo-tree deletes old buffers for the
file paths before the rename, and opens new buffers for files after the
rename. If old buffers were shown in some Neovim window, the code opens
the new buffers in these windows.
The code that handles modified buffers during rename calls `silent!
write!` on the new buffers. This no longer crashes Neovim. The downside
is that LSP clients are not attached at the moment `write!` is called,
which means the files after the rename will not be formatted after
neo-tree saves the modified content. Overall, this seems like a lesser
evil compared to Neovim crashing on each rename.
Related to #308
[0]: https://github.com/neovim/neovim/blob/234b8c5f3d57294dda06dbc6c1760e5983bd2c19/runtime/lua/vim/lsp/util.lua#L751-L775
0 commit comments