-
Notifications
You must be signed in to change notification settings - Fork 206
Fix TextDocumentContentChangeEvents getting applied in the wrong order #603
Conversation
When there are multiple events in one didChange notification
What is the problem in #538? |
BTW, this code has nothing to do with the file that ghc/ghc-mod views. That is handled by the VFS portion of haskell-lsp. So it shouldn't effect those issues you listed. The code that you changed only deals with correlating positions in the new version of the file as compared to the old one which we have a TypecheckedModule for. It has no effect on the file that is sent to GHC for compilation. The purpose of this code is the following: Suppose the original version of the file is
HIE will compile this file and generate a typechecked module for it. now suppose the user edits it to
HIE will fail to compile this file, but we will still have the typechecked module for the old file. Now suppose the user hovers over putStrLn. HIE will get a hover event for line 3, column 3. newPosToOld will tell us that L3C3 corresponds to L2C3 in the old file we have the typechecked module for. Similarly, oldPosToNew will tell us that L2C3 in the old file corresponds to L3C3 in the new file. |
I see, that makes sense. I'm not sure how the position map is affecting the diagnostics then. Where do the Core.NotDidChangeTextDocument notification -> do
liftIO $ U.logm "****** reactor: processing NotDidChangeTextDocument"
let
params = notification ^. J.params
vtdi = params ^. J.textDocument
uri = vtdi ^. J.uri
ver = vtdi ^. J.version
J.List changes = params ^. J.contentChanges
mapFileFromVfs versionTVar cin vtdi
makeRequest $ GReq (Just uri) Nothing Nothing (const $ return ()) $
-- mark this module's cache as stale
pluginGetFile "markCacheStale:" uri $ \fp -> do
markCacheStale fp
-- Important - Call this before requestDiagnostics
updatePositionMap uri changes
requestDiagnostics cin uri ver |
haskell-lsp automatically processes changes to maintain a VFS here: https://github.com/alanz/haskell-lsp/blob/master/src/Language/Haskell/LSP/VFS.hs
|
Looks like the changes are getting sorted by range here. However the specification seems to vaguely imply that they should be applied in the order they come in.
And the behaviour from VS Code would suggest this too. I still think the position mapping would have been in the wrong order, since it doesn't look like the changes there are getting sorted but they are in the VFS. Should we just apply the changes with the order as-is? |
I think the best approach would be to see what vscode actually sends, then write tests that confirm that our implementation conforms to that. |
From typing
Since currently it's being sorted in descending order then the undo part will get processed in the right order, i.e. remove |
There is discussion on the lsp spec repo about these changes, and that they should be applied in reverse order, basically because the origin locations are wrt the original document, so applying an edit at the front will invalidate one at the end. How does this show up as a problem for us? |
@bubba, what needs to happen here? I merged the haskell-lsp commit. |
@wz1000 are you happy with this? |
yes |
When there are multiple events in one didChange notification, they were getting applied from the last event to the first event which caused the text getting out of sync when undoing/redoing in VS Code. Fixes #566, possibly #531 but not #538