The base protocol now offers support for request cancellation. To cancel a request,
a notification message with the following properties is sent:
A notification sent from the client to the server to signal the change of configuration settings.
The document change notification is sent from the client to the server to signal changes to a text document.
In 2.0 the shape of the params has changed to include proper version numbers and language ids.
The watched files notification is sent from the client to the server when the client detects changes to files and folders
watched by the language client (note although the name suggest that only file events are sent it is about file system events which include folders as well).
It is recommended that servers register for these file system events using the registration mechanism.
In former implementations clients pushed file events without the server actively asking for it.
The workspace/didChangeWorkspaceFolders notification is sent from the client to the server to inform the server
about workspace folder configuration changes
The document close notification is sent from the client to the server when the document got closed in the client.
The document’s truth now exists where the document’s uri points to (e.g. if the document’s uri is a file uri
the truth now exists on disk).
The did create files notification is sent from the client to the server when files were created from within the client.
The did delete files notification is sent from the client to the server when files were deleted from within the client.
The document open notification is sent from the client to the server to signal newly opened text documents.
The document’s truth is now managed by the client and the server must not try to read the document’s truth
using the document’s uri.
The did rename files notification is sent from the client to the server when files were renamed from within the client.
The document save notification is sent from the client to the server when the document was saved in the client.
A notification to ask the server to exit its process.
The server should exit with success code 0 if the shutdown request has been received before;
otherwise with error code 1.
The initialized notification is sent from the client to the server after the client received
the result of the initialize request but before the client is sending any other request or
notification to the server. The server can use the initialized notification for example to
dynamically register capabilities.
The log message notification is sent from the server to the client to ask the client to log a particular message.
A notification to log the trace of the server’s execution.
The amount and content of these notifications depends on the current trace configuration.
The progress notification is sent from the server to the client to ask
the client to indicate progress.
Diagnostics notification are sent from the server to the client to signal results of validation runs.
A notification that should be used by the client to modify the trace
setting of the server.
The show message notification is sent from a server to a client to ask the client to display a particular message
in the user interface.
The telemetry notification is sent from the server to the client to ask the client to log a telemetry event.
The protocol doesn’t specify the payload since no interpretation of the data happens in the protocol. Most clients even don’t handle
the event directly but forward them to the extensions owning the corresponding server issuing the event.
The document will save notification is sent from the client to the server before the document
is actually saved.
The window/workDoneProgress/cancel notification is sent from the client
to the server to cancel a progress initiated on the server side using the window/workDoneProgress/create.