The workspace/applyEdit request is sent from the server to the client to modify resource on the
client side.
The code action request is sent from the client to the server to compute commands for a given text document
and range. The request is triggered when the user moves the cursor into a problem marker in the editor or
presses the lightbulb associated with a marker.
The request is sent from the client to the server to resolve additional information for a given code action.
This is usually used to compute the edit property of a code action to avoid its unnecessary computation
during the textDocument/codeAction request.
The workspace/codeLens/refresh request is sent from the server to the client.
Servers can use it to ask clients to refresh the code lenses currently shown in editors.
As a result the client should ask the server to recompute the code lenses for these editors.
This is useful if a server detects a configuration change which requires a re-calculation of all code lenses.
Note that the client still has the freedom to delay the re-calculation of the code lenses if for example an editor is currently not visible.
The code lens request is sent from the client to the server to compute code lenses for a given text document.
The code lens resolve request is sent from the client to the server to resolve the command for a
given code lens item.
The color presentation request is sent from the client to the server to obtain a list of presentations for a color value
at a given location.
The Completion request is sent from the client to the server to compute completion items at a given cursor position.
Completion items are presented in the IntelliSense user interface. If computing full completion items is expensive,
servers can additionally provide a handler for the completion item resolve request (‘completionItem/resolve’).
This request is sent when a completion item is selected in the user interface. A typical use case is for example:
the ‘textDocument/completion’ request doesn’t fill in the documentation property for returned completion items
since it is expensive to compute. When the item is selected in the user interface then a ‘completionItem/resolve’
request is sent with the selected completion item as a param. The returned completion item should have the
documentation property filled in. The request can delay the computation of the detail and documentation properties.
However, properties that are needed for the initial sorting and filtering, like sortText, filterText, insertText,
and textEdit must be provided in the textDocument/completion request and must not be changed during resolve.
The document color request is sent from the client to the server to list all color references found in a given text document.
Along with the range, a color value in RGB is returned.
The document highlight request is sent from the client to the server to resolve a document highlights
for a given text document position.
For programming languages this usually highlights all references to the symbol scoped to this file.
However we kept ‘textDocument/documentHighlight’ and ‘textDocument/references’ separate requests since
the first one is allowed to be more fuzzy.
Symbol matches usually have a DocumentHighlightKind of Read or Write whereas fuzzy or textual matches
use Text as the kind.
The document links request is sent from the client to the server to request the location of links in a document.
The document link resolve request is sent from the client to the server to resolve the target of
a given document link.
The document symbol request is sent from the client to the server to list all symbols found in a given
text document.
The workspace/executeCommand request is sent from the client to the server to trigger command execution on the server.
In most cases the server creates a WorkspaceEdit structure and applies the changes to the workspace using the request
workspace/applyEdit which is sent from the server to the client.
The folding range request is sent from the client to the server to return all folding ranges found in a given text document.
The document formatting request is sent from the server to the client to format a whole document.
The goto definition request is sent from the client to the server to resolve the definition location of
a symbol at a given text document position.
The goto implementation request is sent from the client to the
server to resolve the implementation location of a symbol at a
given text document position.
The goto type definition request is sent from the client to the
server to resolve the type definition location of a symbol at a
given text document position.
The hover request is sent from the client to the server to request hover information at a given text
document position.
The initialize request is sent as the first request from the client to the server.
If the server receives request or notification before the initialize request it should act as follows:
The linked editing request is sent from the client to the server to return for a given position in a document
the range of the symbol at the position and all ranges that have the same content.
Optionally a word pattern can be returned to describe valid contents. A rename to one of the ranges can be applied
to all other ranges if the new content is valid. If no result-specific word pattern is provided, the word pattern from
the client’s language configuration is used.
The document on type formatting request is sent from the client to the server to format parts of
the document during typing.
The prepare rename request is sent from the client to the server to setup and test the validity of a rename operation
at a given location.
The document range formatting request is sent from the client to the server to format a given range in a document.
The references request is sent from the client to the server to resolve project-wide references for the
symbol denoted by the given text document position.
The client/registerCapability request is sent from the server to the client to register for a new capability
on the client side. Not all clients need to support dynamic capability registration. A client opts in via the
ClientCapabilities.GenericCapability property.
The rename request is sent from the client to the server to perform a workspace-wide rename of a symbol.
The request is sent from the client to the server to resolve additional information for a given completion item.
The selection range request is sent from the client to the server to return
suggested selection ranges at given positions. A selection range is a range
around the cursor position which the user might be interested in selecting.
The workspace/semanticTokens/refresh request is sent from the server to the client.
Servers can use it to ask clients to refresh the editors for which this server provides semantic tokens.
As a result the client should ask the server to recompute the semantic tokens for these editors.
This is useful if a server detects a project wide configuration change which requires a re-calculation of all semantic tokens.
Note that the client still has the freedom to delay the re-calculation of the semantic tokens if for example an editor is currently not visible.
The show document request is sent from a server to a client to ask the client to display a particular document in the user interface.
The show message request is sent from a server to a client to ask the client to display a particular message
in the user interface. In addition to the show message notification the request allows to pass actions and to
wait for an answer from the client.
The shutdown request is sent from the client to the server. It asks the server to shut down,
but to not exit (otherwise the response might not be delivered correctly to the client).
There is a separate exit notification that asks the server to exit.
The signature help request is sent from the client to the server to request signature information at
a given cursor position.
The client/unregisterCapability request is sent from the server to the client to unregister a
previously register capability.
The will create files request is sent from the client to the server before files are actually created as long as the creation is triggered from within the client. The request can return a WorkspaceEdit which will be applied to workspace before the files are created. Please note that clients might drop results if computing the edit took too long or if a server constantly fails on this request. This is done to keep creates fast and reliable.
The will delete files request is sent from the client to the server before files are actually deleted as long as the deletion is triggered from within the client. The request can return a WorkspaceEdit which will be applied to workspace before the files are deleted. Please note that clients might drop results if computing the edit took too long or if a server constantly fails on this request. This is done to keep deletes fast and reliable.
The will rename files request is sent from the client to the server before files are actually renamed as long as the rename is triggered from within the client. The request can return a WorkspaceEdit which will be applied to workspace before the files are renamed. Please note that clients might drop results if computing the edit took too long or if a server constantly fails on this request. This is done to keep renames fast and reliable.
The document will save request is sent from the client to the server before the document is
actually saved. The request can return an array of TextEdits which will be applied to the text
document before it is saved. Please note that clients might drop results if computing the text
edits took too long or if a server constantly fails on this request. This is done to keep the
save fast and reliable.
The window/workDoneProgress/create request is sent from the server
to the clientto ask the client to create a work done progress.
The workspace/configuration request is sent from the server to the client to fetch configuration settings
from the client. The request can fetch several configuration settings in one roundtrip.
The order of the returned configuration settings correspond to the order of the passed ConfigurationItems
(e.g. the first item in the response is the result for the first configuration item in the params).
The workspace/workspaceFolders request is sent from the server to the client to fetch the current open list of
workspace folders. Returns null in the response if only a single file is open in the tool.
Returns an empty array if a workspace is open but no folders are configured.
The workspace symbol request is sent from the client to the server to list project-wide symbols
matching the query string.