Skip to content

Ensure document state synchronization before client requests #2017

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Mar 31, 2025
Merged

Ensure document state synchronization before client requests #2017

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
b8fa66b
Added description about the order of `signatureHelp` and `didChange`
imbant Sep 11, 2024
eb889f5
Revert the specific description about the order of didChange
imbant Sep 12, 2024
a47896f
Ensure document state synchronization before client requests
imbant Sep 12, 2024
d0d766a
Ensure document state synchronization before client requests
imbant Sep 12, 2024
c28b371
Merge branch 'gh-pages' into imbant-signatureHelp
imbant Sep 12, 2024
d4ac04c
add a concrete example
imbant Sep 13, 2024
a22a806
add a concrete example
imbant Sep 13, 2024
0670194
Merge branch 'gh-pages' into imbant-signatureHelp
dbaeumer Mar 31, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions _specifications/lsp/3.17/textDocument/didChange.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,16 @@

The document change notification is sent from the client to the server to signal changes to a text document. Before a client can change a text document it must claim ownership of its content using the `textDocument/didOpen` notification. In 2.0 the shape of the params has changed to include proper version numbers.

Before requesting information from the server (e.g., `textDocument/completion` or `textDocument/signatureHelp`), the client must ensure that the document's state is synchronized with the server to guarantee reliable results.
Copy link
Member

@dbaeumer dbaeumer Sep 13, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to make this more concrete since this sentences allows for interpretation as well (e.g. another change occurers before the client sends the request). So in a sequence

<document change one><code complete><document change two> the client needs to sync <document change one> to the server before requesting code compltion but not document change two.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. I added your example with a timeline table


The following example shows how the client should synchronize the state when the user has continuous input, assuming user input triggered `textDocument/completion`:

| Document Version | User Input | Client Behavior | Request |
| ---------------- | ------------------- | ----------------------------------------------- | ------------------------- |
| 5 | document change one | sync document `v5` to the server | `textDocument/didChange` |
| 5 | - | request from the server, based on document `v5` | `textDocument/completion` |
| 6 | document change two | sync document `v6` to the server | `textDocument/didChange` |

_Client Capability_:
See general synchronization [client capabilities](#textDocument_synchronization_cc).

Expand Down
10 changes: 10 additions & 0 deletions _specifications/lsp/3.18/textDocument/didChange.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,16 @@

The document change notification is sent from the client to the server to signal changes to a text document. Before a client can change a text document it must claim ownership of its content using the `textDocument/didOpen` notification. In 2.0 the shape of the params has changed to include proper version numbers.

Before requesting information from the server (e.g., `textDocument/completion` or `textDocument/signatureHelp`), the client must ensure that the document's state is synchronized with the server to guarantee reliable results.

The following example shows how the client should synchronize the state when the user has continuous input, assuming user input triggered `textDocument/completion`:

| Document Version | User Input | Client Behavior | Request |
| ---------------- | ------------------- | ----------------------------------------------- | ------------------------- |
| 5 | document change one | sync document `v5` to the server | `textDocument/didChange` |
| 5 | - | request from the server, based on document `v5` | `textDocument/completion` |
| 6 | document change two | sync document `v6` to the server | `textDocument/didChange` |

_Client Capability_:
See general synchronization [client capabilities](#textDocument_synchronization_cc).

Expand Down