Why signature help doesn't provide the version of current document?

[imbant]

In the document, the only thing textDocument/signatureHelp provides about the current document is the uri of it.

If the language server don't know the version, is it possible to confirm or constrain the didChange request to be later than signatureHelp ? Because usually when the document content changes, the language server needs to re-compile to obtain the information required by signature help. The language server needs to handle signature help after compiling, or, the language server can know that the content didn't change by comparing document versions between signatureHelp and didChange

[dbaeumer]

The LSP protocol ensures that any outstanding document change requests are sent to the server. The server should see the document in exactly the same state as the client saw it when the signature help request got triggered. If you see a different behavior please open a corresponding issue against the client implementation. For VS Code here: https://github.com/Microsoft/vscode-languageserver-node

[imbant]

@dbaeumer Hi, thank you for your attention.

I think there is a same issue for both client and server:
Is textDocument/didChange always before textDocument/signatureHelp ?
It seems LSP doesn't declare it.

If not, for my case, signatureHelp may need the textdocument's version to make sure didChange happened and can get access to the latest semantic information, because my language server will recompile after didChange, rather than signatureHelp

[dbaeumer]

I am not sure I understand this. The spec is clear that clients can't reorder events and that servers should only reorder events if they know what they do. Can you point me to an example were you receive a request before the change event is received and it should actually have happened the other way around?

If you need the document version it is part of the change event. So you server can ensure that the recompiled version adheres to the version number when receving signature help.

[imbant]

I think the way I expressed it before was misleading. Let me rephrase the question: After the user hits the keyboard, can the language server confirm that the change event always occurs before the signature help event?

I debugged it and it seems to be the case, but the protocol does not seem to have this requirement. So I want to confirm

[dbaeumer]

Yes, clients should keep event orders. So if a user types and the client decides to ask for signature help the change event must be delivered to the server before the signature help request is sent. This being said if the user continues typing the client should cancel the previous signature help request and send a new one.

[imbant]

Thanks for your response. Now I know how to handle this.

I think this conclusion may help other language server developers if they are working on signature help. So I add this PR #2017 and hope this may can be added to the lsp document.

If there is anything I can improve please let me know, thanks again

[rchl]

Your suggestion for the spec change is very specific. Possibly too specific.

It generally makes sense that any request that asks server for something (definition, completions, signature help, etc) needs to be done on the latest version of the document to give reliable results. And the way to do that is to notify server about document change first.

[imbant]

@rchl Hi. I see. Especially completions and signature help, these two request both have a triggerCharacter, whitch means user input may trigger not only didChange but also these request.

Maybe the documentation should state this?

[dbaeumer]

I agree with @rchl that this sentence is too specific and may cause more confusion since we would only state this for two requests.

And for the trigger character it is the same as every other character. The state of the document must be sync to the server as it is seen when the request is trigger on the client.

I am not against a general sentence in the spec in the are of text document changes.

[imbant]

I tried to summarize our conversation in the area of text document changes and updated the PR:

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.