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 text document diagnostic request is sent from the client to the server to ask the server to
compute the diagnostics for a given document. As with other pull requests the server is asked
to compute the diagnostics for the currently synced version of the document.
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 workspace/inlayHint/refresh request is sent from the server to the client. Servers can use
it to ask clients to refresh the inlay hints currently shown in editors. As a result the client
should ask the server to recompute the inlay hints for these editors. This is useful if a server
detects a configuration change which requires a re-calculation of all inlay hints. Note that the
client still has the freedom to delay the re-calculation of the inlay hints if for example an
editor is currently not visible.
The inlay hints request is sent from the client to the server to compute inlay hints for a given
[text document, range] tuple that may be rendered in the editor in place with other text.
The inlayHint/resolve request is sent from the client to the server to resolve additional
information for a given inlay hint. This is usually used to compute the tooltip, location or
command properties of a inlay hint’s label part to avoid its unnecessary computation during the
textDocument/inlayHint request.
The workspace/inlineValue/refresh request is sent from the server to the client. Servers can
use it to ask clients to refresh the inline values currently shown in editors. As a result the
client should ask the server to recompute the inline values for these editors. This is useful if
a server detects a configuration change which requires a re-calculation of all inline values.
Note that the client still has the freedom to delay the re-calculation of the inline values if
for example an editor is currently not visible.
The inline value request is sent from the client to the server to compute inline values for a
given text document that may be rendered in the editor at the end of lines.
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 type hierarchy request is sent from the client to the server to return a type hierarchy for
the language element of given text document positions. Will return null if the server couldn’t
infer a valid type from the position. The type hierarchy requests are executed in two steps:
The typeHierarchy/subtypes request is sent from the client to the server to resolve the
subtypes for a given type hierarchy item. Will return null if the server couldn’t infer a valid
type from item in the params. The request doesn’t define its own client and server capabilities.
It is only issued if a server registers for the textDocument/prepareTypeHierarchy request.
The typeHierarchy/supertypes request is sent from the client to the server to resolve the
supertypes for a given type hierarchy item. Will return null if the server couldn’t infer a
valid type from item in the params. The request doesn’t define its own client and server
capabilities. It is only issued if a server registers for the
textDocument/prepareTypeHierarchy request.
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 client to 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/diagnostic/refresh request is sent from the server to the client. Servers can
use it to ask clients to refresh all needed document and workspace diagnostics. This is useful
if a server detects a project wide configuration change which requires a re-calculation of all
diagnostics.
The workspace diagnostic request is sent from the client to the server to ask the server to
compute workspace wide diagnostics which previously where pushed from the server to the client.
In contrast to the document diagnostic request the workspace request can be long running and is
not bound to a specific workspace or document state. If the client supports streaming for the
workspace diagnostic pull it is legal to provide a document diagnostic report multiple times
for the same document URI. The last one reported will win over previous reports.
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.
The workspaceSymbol/resolve request is sent from the client to the server to resolve
additional information for a given workspace symbol.