A special text edit with an additional change annotation.
Represents an incoming call, e.g. a caller of a method or constructor.
Represents an outgoing call, e.g. calling a getter from a method or a method from a constructor etc.
Additional information that describes document changes.
Where ClientCapabilities are currently empty:
Whether the client supports resolving additional code action
properties via a separate codeAction/resolve request.
Contains additional diagnostic information about the context in which
a code action is run.
Params for the CodeActionRequest
The reason why code actions were requested.
A code lens represents a command that should be shown along with
source text, like the number of references, a way to run tests, etc.
Code Lens options.
Represents a reference to a command. Provides a title which will be used to represent a command in the UI.
Commands are identified by a string identifier. The recommended way to handle commands is to implement
their execution on the server side if the client and server provides the corresponding capabilities.
Alternatively the tool extension code could handle the command.
The protocol currently doesn’t specify a set of well-known commands.
The kind of a completion entry.
Additional details for a completion item label.
Completion options.
How a completion was triggered.
Create file operation
Options to create a file.
The parameters sent in notifications/requests for user-initiated creation
of files.
Delete file operation
Delete file options
The parameters sent in notifications/requests for user-initiated deletes
of files.
Represents a diagnostic, such as a compiler error or warning.
Diagnostic objects are only valid in the scope of a resource.
Client capabilities specific to diagnostic pull requests.
Diagnostic options.
Diagnostic registration options.
Represents a related message and source code location for a diagnostic. This
should be used to point to code locations that cause or related to a
diagnostics, e.g when duplicating a symbol in a scope.
Cancellation data returned from a diagnostic request.
The protocol currently supports the following diagnostic severities:
The diagnostic tags.
Workspace client capabilities specific to diagnostic pull requests.
Describe options to be used when registered for text document change events.
Parameters of the document diagnostic request.
A partial result for a document diagnostic report.
A document filter denotes a document through properties like language, schema or pattern.
Examples are a filter that applies to TypeScript files on disk or a filter the applies to JSON
files with name package.json:
A document highlight is a range inside a text document which deserves
special attention. Usually a document highlight is visualized by changing
the background color of its range.
A document highlight kind.
A document link is a range in a text document that links to an internal or external resource, like another
text document or a web site.
Format document on type options
Extends TextDocumentRegistrationOptions
Represents programming constructs like variables, classes, interfaces etc.
that appear in a document. Document symbols can be hierarchical and they have two ranges:
one that encloses its definition and one that points to its most interesting range,
e.g. the range of an identifier.
Execute command options.
Execute command registration options.
The file event type.
Represents information on a file/folder create.
Represents information on a file/folder delete.
An event describing a file change.
A filter to describe in which file operation requests or notifications
the server is interested in.
A pattern to describe in which file operation requests or notifications
the server is interested in.
Matching options for the file operation pattern.
The options to register for file operations.
Represents information on a file/folder rename.
Represents a folding range.
Value-object describing what options formatting should use.
A diagnostic report with a full set of problems.
The result of a hover request.
Hover options.
Inlay hint information.
Inlay hint client capabilities.
Inlay hint kinds.
An inlay hint label part allows for interactive and composite labels
of inlay hints.
Inlay hint options used during static registration.
A parameter literal used in inlay hint requests.
Inlay hint options used during static or dynamic registration.
Inlay hint client capabilities.
Client workspace capabilities specific to inlay hints.
@since 3.17.0
Provide an inline value through an expression evaluation.
Inline value options used during static registration.
A parameter literal used in inline value requests.
Inline value options used during static or dynamic registration.
Provide inline value as text.
Provide inline value through a variable lookup.
Client workspace capabilities specific to inline values.
A special text edit to provide an insert and a replace operation.
Defines how to interpret the insert text in a completion item
How whitespace and indentation is handled during completion
item insertion.
Represents a location inside a resource, such as a line inside a text file.
Represents a link between a source and a target location.
A
MarkupContent literal represents a string value which content can be represented in different formats.
Currently
plaintext and
markdown are supported formats. A
MarkupContent is usually used in
documentation properties of result literals like
CompletionItem or
SignatureInformation.
If the format is
markdown the content should follow the
GitHub Flavored Markdown Specification.
Moniker definition to match LSIF 0.5 moniker definition.
An identifier which optionally denotes a specific version of a text document. This information usually flows from the server to the client
Represents a parameter of a callable-signature. A parameter can
have a label and a doc-comment.
A parameter literal used to pass a partial result token.
Position in a text document expressed as zero-based line and character offset.
A position is between two characters like an ‘insert’ cursor in a editor.
A type indicating how positions are encoded,
specifically what column offsets mean.
A previous result ID in a workspace pull request.
The progress notification is sent from the server to the client to ask
the client to indicate progress.
A range in a text document expressed as (zero-based) start and end positions.
A range is comparable to a selection in an editor. Therefore the end position is exclusive.
General parameters to to register for a capability.
A full diagnostic report with a set of related documents.
An unchanged diagnostic report with a set of related documents.
A relative pattern is a helper to construct glob patterns that are matched
relatively to a base URI. The common value for a baseUri is a workspace
folder root, but it can be another absolute URI as well.
Rename file operation
Rename file options
The parameters sent in notifications/requests for user-initiated renames
of files.
Save options.
Represents a selection range.
A parameter literal used in selection range requests.
The actual tokens.
A set of predefined token modifiers. This set is not fixed
and clients can specify additional token types via the
corresponding client capabilities.
A set of predefined token types. This set is not fixed
and clients can specify additional token types via the
corresponding client capabilities.
@since 3.16.0
Capabilities specific to the textDocument/semanticTokens/* requests.
@since 3.16.0
@since 3.16.0
@since 3.16.0
@since 3.16.0
@since 3.16.0
Client capabilities for the show document request.
Params to show a document.
The result of an show document request.
Show message request client capabilities
Signature help represents the signature of something
callable. There can be multiple signature but only one
active and only one active parameter.
Signature help options.
Signature help options.
Signature help options.
Represents the signature of something callable. A signature
can have a label, like a function-name, a doc-comment, and
a set of parameters.
Client capability that signals how the client
handles stale requests (e.g. a request
for which the client will not process the response
anymore since the information is outdated).
Represents information about programming constructs like variables, classes,
interfaces etc.
A symbol kind.
Specific capabilities for the SymbolKind in the workspace/symbol request.
Symbol tags are extra annotations that tweak the rendering of a symbol.
Describe options to be used when registering for text document change events.
Text document specific client capabilities.
An event describing a change to a text document. If range and rangeLength are omitted
the new text is considered to be the full content of the document.
Describes textual changes on a single text document. The text document is referred to as a
OptionalVersionedTextDocumentIdentifier to allow clients to check the text document version before an
edit is applied. A TextDocumentEdit describes all changes on a version Si and after they are
applied move the document to version Si+1. So the creator of a TextDocumentEdit doesn’t need to
sort the array or do any kind of ordering. However the edits must be non overlapping.
Text documents are identified using a URI. On the protocol level, URIs are passed as strings.
An item to transfer a text document from the client to the server.
A parameter literal used in requests to pass a text document and a position inside that document.
Since most of the registration options require to specify a document selector there is a base
interface that can be used.
Represents reasons why a text document is saved.
Defines how the host (editor) should sync document changes to the language server.
A textual edit applicable to a text document.
A diagnostic report indicating that the last returned report is still accurate.
General parameters to unregister a capability.
A parsed URL record.
An identifier to denote a specific version of a text document. This information usually flows from the client to the server.
The parameters send in a will save text document notification.
Window specific client capabilities.
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.
The window/workDoneProgress/create request is sent
from the server to the client to ask the client to create a work done progress.
An optional token that a server can use to report work done progress
Workspace specific client capabilities.
Parameters of the workspace diagnostic request.
A workspace diagnostic report.
A partial result for a workspace diagnostic report.
A workspace edit represents changes to many resources managed in the workspace.
The edit should either provide changes or documentChanges.
If the client can handle versioned document edits and if documentChanges are present,
the latter are preferred over changes.
The workspace folder change event.
A full document diagnostic report for a workspace diagnostic result.
A special workspace symbol that supports locations without a range
The parameters of a Workspace Symbol Request.
An unchanged document diagnostic report for a workspace diagnostic result.
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 result of a document diagnostic pull request.
The document diagnostic report kinds.
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.
A pattern kind describing if a glob pattern matches a file a folder or
both.
Enum of known range kinds
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 glob pattern. Either a string pattern or a relative pattern.
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.
GotoDefinition response can be single location, or multiple Locations or a link.
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.
Hover contents could be single entry or multiple entries.
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.
Inline value information can be provided by different means:
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.
MarkedString can be used to render human readable text. It is either a
markdown string or a code-block that provides a language and a code snippet.
The language identifier is semantically equal to the optional language
identifier in fenced code blocks in GitHub issues.
Describes the content type that a client supports in various
result literals like Hover, ParameterInfo or CompletionItem.
The moniker kind.
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.
A TraceValue represents the level of verbosity with which the server systematically
reports its execution trace using LogTrace notifications.
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.
Moniker uniqueness level to define scope of the moniker.
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.
A workspace diagnostic document report.
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.