-
-
Notifications
You must be signed in to change notification settings - Fork 384
Description
Describe the bug
The client can, in certain situations, send the contents of the entire file all over again by closing the file (textDocument/didClose
) and opening it again (textDocument/didOpen
) with the new contents. For example, Nvim does that if it "reloads" the file, which can happen if it is modified by some other process outside of the editor. However, this breaks lua-language-server because it doesn't properly resolve text edits sent with textDocument/didChange
after the file is "reloaded" - it uses the previous state of the file to apply text edits and generate diagnostics.
To Reproduce
Steps to reproduce the behavior:
a.lua
function func1() if test2 then print(1) end print(2) end func1()
b.lua
function func1() print(1) print(2) print(3) end func1()
$ cp a.lua c.lua
$ nvim c.lua
- Make any edit in
c.lua
,2gg>>u
will do $ cp b.lua c.lua
(don't close the editor, this will cause a "reload" of the file)- Return to the editor, make an edit which would cause a syntax error if it was done in
a.lua
, e.g.4ggI--
- Misplaced and irrelevant diagnostics!
Expected behavior
After Nvim sends the the didClose
and didOpen
pair of events (responsible code), subsequent text edits should apply to the new contents (b.lua
) and not the previous ones (a.lua
).
Screenshots
An example of misplaced diagnostics with c.lua
's contents same as b.lua
:
Notice how they are correct if applied to a.lua
with the text edit:
Environment (please complete the following information):
- OS: Arch Linux
- Client: neovim 0.5.1
Additional context
I already have a PR ready for this, I'm opening a bug ticket just for formality.