Feature suggestion: server can send idle notification to signal readiness

[squidfunk]

Problem

From my understanding of the spec, the language client has currently no way to know the state of the server, e.g. whether the server is still busy processing textDocument/did* events, updating the language model, or whatever it needs to do on changes. Thus, after sending a textDocument/didChange notification, some clients impose an arbitrary delay, before language features are requested from the server, like for example textDocument/documentSymbol.

Proposed solution

A language server could send an idle notification to the language client, for which a client could register. Each time the language server receives a notification, it can send an idle notification after finishing processing, to signal that the language model has been updated and the server is able to handle requests again. The debouncing that is already happening on the client-side could then be interrupted by the receiving of such a notification, making typing more instant for language servers that are fast. It would be downward-compatible since clients would have to support it deliberately.

Related

• LSP textDocument/documentSymbol is delayed by ~350ms vscode#135453
• Sublime LSP waits for 300ms after the last keystroke before sending textDocument/didChange

[dbaeumer]

Actually we decided it solve this different. Server can (mostly for new request) signal a busy state which asks the client to resend the request.

See ServerCancelled here https://microsoft.github.io/language-server-protocol/specifications/specification-3-17/#errorCodes

A client needs to opt in into this but it would need opt into an idle request as well.

[squidfunk]

Thanks for the answer. The problem I see with this is that the client won't know without asking the server that the server is still busy, so an initial request must always be sent. This doesn't allow for short-circuiting debounce intervals, as it only tells the client to "ask later", without specifying what later is (which is of course impossible). A push-based approach would have the benefit of being easier to react to on the client side.