Skip to content

Conversation

mfussenegger
Copy link

@mfussenegger mfussenegger commented Apr 14, 2021

Clients like the one built into neovim reject edits where the version is
lower than the expected document version.

This was always the case with hls because the version is hardcoded to 0.
vscode seems to accept that, but based on the specification it is more
accurate to set the version to null if it is not know.

The textDocument of TextDocumentEdit has the type
OptionalVersionedTextDocumentIdentifier


Update: Figured out that in 3.15 the textDocument was a VersionedTextDocumentIdentifier. We merged a change in neovim to allow 0 versions as well so I guess this PR is obsolete.

Clients like the one built into neovim reject edits where the version is
lower than the expected document version.

This was always the case with hls because the version is hardcoded to 0.
vscode seems to accept that, but based on the specification it is more
accurate to set the version to `null` if it is not know.

The `textDocument` of `TextDocumentEdit` has the type
`OptionalVersionedTextDocumentIdentifier`
@mfussenegger mfussenegger marked this pull request as draft April 14, 2021 18:59
mfussenegger added a commit to mfussenegger/neovim that referenced this pull request Apr 14, 2021
There were a couple of reports of "Buffer X newer than edits" problems.
We first assumed that it is incorrect for a server to send 0 as a
version - and stated that they should send a `null` instead, given that
in the specification the `textDocument` of a `TextDocumentEdit` is a
`OptionalVersionedTextDocumentIdentifier`.

But it turns out that this was a change in 3.16, and in 3.15 and earlier
versions of the specification it was a `VersionedTextDocumentIdentifier`
and language servers didn't have a better option than sending `0` if
they don't keep track of the version numbers.

So this changes the version check to always accept `0` values.

See

- neovim#12970
- neovim#14256
- haskell/haskell-language-server#1727
@mfussenegger mfussenegger marked this pull request as ready for review April 14, 2021 20:45
@Ailrun
Copy link
Member

Ailrun commented Apr 15, 2021

If this is obsolete, could you please close this?

@mfussenegger
Copy link
Author

If this is obsolete, could you please close this?

Sure

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants