language-servers/language-server-protocol
1
0
Fork 0
mirror of https://github.com/microsoft/language-server-protocol.git synced 2025-12-23 08:48:16 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Markdown whitespace formatting improvements (#2172)

Browse source 
Normalize markdown whitespace

Co-authored-by: Dirk Bäumer <dirkb@microsoft.com>
This commit is contained in:
Peter Tripp 2025-08-06 09:21:17 -04:00 • committed by GitHub
parent c41319b3a1
commit 0003fb53f1
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
75 changed files with 266 additions and 270 deletions
Download patch file Download diff file Expand all files Collapse all files

2
_includes/messages/3.17/registerCapability.md
View file

@ -104,4 +104,4 @@ export interface TextDocumentRegistrationOptions {
*/
documentSelector: DocumentSelector | null;
}
```
```

2
_includes/types/enumerations.md
View file

@ -1,4 +1,4 @@
#### <a href="#enumerations" name="enumerations" class="anchor"> Enumerations </a>
#### <a href="#enumerations" name="enumerations" class="anchor">Enumerations</a>
The protocol supports two kind of enumerations: (a) integer based enumerations and (b) string based enumerations. Integer based enumerations usually start with `1`. The ones that don't are historical and they were kept to stay backwards compatible. If appropriate, the value set of an enumeration is announced by the defining side (e.g. client or server) and transmitted to the other side during the initialize handshake. An example is the `CompletionItemKind` enumeration. It is announced by the client using the `textDocument.completion.completionItemKind` client property.

4
_includes/types/traceValue.md
View file

@ -1,8 +1,8 @@
#### <a href="#traceValue" name="traceValue" class="anchor"> TraceValue </a>
#### <a href="#traceValue" name="traceValue" class="anchor">TraceValue</a>
A `TraceValue` represents the level of verbosity with which the server systematically reports its execution trace using [$/logTrace](#logTrace) notifications.
The initial trace value is set by the client at initialization and can be modified later using the [$/setTrace](#setTrace) notification.
```typescript
export type TraceValue = 'off' | 'messages' | 'verbose';
```
```

2
_includes/types/uri.md
View file

@ -1,4 +1,4 @@
#### <a href="#uri" name="uri" class="anchor"> URI </a>
#### <a href="#uri" name="uri" class="anchor">URI</a>
URI's are transferred as strings. The URI's format is defined in [https://tools.ietf.org/html/rfc3986](https://tools.ietf.org/html/rfc3986)

2
_overviews/lsif/overview.md
View file

@ -132,4 +132,4 @@ To get started with LSIF, you can have a look at the following resources:
- The [LSIF specification](../../../specifications/lsif/0.4.0/specification) - The document also describes some additional optimizations that have been done to keep the emitted data compact.
- [LSIF Index for TypeScript](https://github.com/Microsoft/lsif-node) - A tool that generates LSIF for TypeScript. The README provides instructions for using the tool.
- [Visual Studio Code extension for LSIF](https://github.com/Microsoft/vscode-lsif-extension) - An extension for VS Code that provides language comprehension features using an LSIF JSON dump. If you implement a new LSIF generator, you can use this extension to validate it with arbitrary source code.
- [Visual Studio Code extension for LSIF](https://github.com/Microsoft/vscode-lsif-extension) - An extension for VS Code that provides language comprehension features using an LSIF JSON dump. If you implement a new LSIF generator, you can use this extension to validate it with arbitrary source code.

50
_specifications/base/0.9/specification.md
View file

@ -9,7 +9,7 @@ index: 3
toolsVersion: 0.9
---
## <a href="#baseProtocol" name="baseProtocol" class="anchor"> Base Protocol </a>
## <a href="#baseProtocol" name="baseProtocol" class="anchor">Base Protocol</a>
The purpose of the base protocol is to create an abstraction of common editor extensibility patterns into its own specification, independently of the presence of a language server powering such extension. In particular, concepts such as server and client capabilities, the initialization and shutdown request, and the structure of requests and notifications, were originally part of the language server protocol, but there is nothing about them that should be exclusive to language service extensions.
@ -17,7 +17,7 @@ A motivating example is the [Build Server Protocol](https://build-server-protoco
Do remark that the base protocol is currently under experimental construction and subject to breaking changes. Its future development will depend on feedback from the community and initial implementors of the protocol.
### <a href="#headerPart" name="headerPart" class="anchor"> Header Part </a>
### <a href="#headerPart" name="headerPart" class="anchor">Header Part</a>
The base protocol consists of a header and a content part (comparable to HTTP). The header and content part are
separated by a '\r\n'.
@ -34,7 +34,7 @@ Currently the following header fields are supported:
The header part is encoded using the 'ascii' encoding. This includes the '\r\n' separating the header and content part.
### <a href="#contentPart" name="contentPart" class="anchor"> Content Part </a>
### <a href="#contentPart" name="contentPart" class="anchor">Content Part</a>
Contains the actual content of the message. The content part of a message uses [JSON-RPC](http://www.jsonrpc.org/) to describe requests, responses and notifications. The content part is encoded using the charset provided in the Content-Type field. It defaults to `utf-8`, which is the only encoding supported right now. If a server or client receives a header with a different encoding than `utf-8` it should respond with an error.
@ -53,7 +53,7 @@ Content-Length: ...\r\n
}
```
### <a href="#capabilities" name="capabilities" class="anchor"> Capabilities </a>
### <a href="#capabilities" name="capabilities" class="anchor">Capabilities</a>
Not every server can support all features defined by a protocol. The base protocol therefore provides "capabilities". A capability groups a set of features. A development tool and the server announce their supported features using capabilities. As an example, a development tool could announce support for document creation notifications, so that servers can perform their corresponding document synchronizations tasks.
@ -100,13 +100,13 @@ Note that the following list of capability identifiers are already used by the l
- `workspace`
- `workspaceSymbolProvider`
### <a href="#messageOrdering" name= "messageOrdering" class="anchor"> Request, Notification and Response Ordering </a>
### <a href="#messageOrdering" name="messageOrdering" class="anchor">Request, Notification and Response Ordering</a>
Responses to requests should be sent in roughly the same order as the requests appear on the server or client side. So, for example, if a server providing unit testing features receives a `testing/configureFramework` request and then a `testing/configureProject` request, it will usually first return the response for the `testing/configureFramework` and then the response for `testing/configureProject`.
However, the server may decide to use a parallel execution strategy and may wish to return responses in a different order than the requests were received. The server may do so as long as this reordering doesn't affect the correctness of the responses. For example, reordering the result of `testing/configureFramework` and `testing/configureProject` is allowed, as each of these requests usually won't affect the output of the other. On the other hand, the server most likely should not reorder `testing/testCreated` and `testing/executeTest` requests, since test creation should happen before their execution.
### <a href="#messageDocumentation" name= "messageDocumentation" class="anchor"> Message Documentation </a>
### <a href="#messageDocumentation" name="messageDocumentation" class="anchor">Message Documentation</a>
As mentioned previously, the base protocol defines a set of requests, responses and notifications. Each of those are documented using the following format:
@ -117,11 +117,11 @@ As mentioned previously, the base protocol defines a set of requests, responses
* a _Request_ section describing the format of the request sent. The method is a string identifying the request, the parameters are documented using a TypeScript interface. It is also documented whether the request supports work done progress and partial result progress.
* a _Response_ section describing the format of the response. The result item describes the returned data in case of a success. The optional partial result item describes the returned data of a partial result notification. The `error.data` describes the returned data in case of an error. Please remember that in case of a failure the response already contains an `error.code` and an `error.message` field. These fields are only specified if the protocol forces the use of certain error codes or messages. In cases where the server can decide on these values freely they aren't listed here.
## <a href="#basicJsonStructures" name="basicJsonStructures" class="anchor"> JSON structures </a>
## <a href="#basicJsonStructures" name="basicJsonStructures" class="anchor">JSON structures</a>
The base protocol uses request, response, and notification objects as specified in the [JSON-RPC protocol](http://www.jsonrpc.org/specification). It currently does not support JSON-RPC batch messages; protocol clients and servers must not send JSON-RPC requests.
#### <a href="#baseTypes" name="baseTypes" class="anchor"> Base Types </a>
#### <a href="#baseTypes" name="baseTypes" class="anchor">Base Types</a>
The base protocol uses the following definitions for integers, unsigned integers, decimal numbers, objects and arrays:
@ -186,7 +186,7 @@ export type BaseArray = BaseAny[];
{% include types/uri.md %}
#### <a href="#regExp" name="regExp" class="anchor"> Regular Expressions </a>
#### <a href="#regExp" name="regExp" class="anchor">Regular Expressions</a>
Regular expressions are a powerful tool and there are actual use cases for them in protocols like LSP. However the downside with them is that almost every programming language has its own set of regular expression features so the base specification can not simply refer to them as a regular expression.
@ -217,7 +217,7 @@ export interface RegularExpressionsClientCapabilities {
}
```
#### <a href="#enumerations" name="enumerations" class="anchor"> Enumerations </a>
#### <a href="#enumerations" name="enumerations" class="anchor">Enumerations</a>
The base protocol supports two kind of enumerations: (a) integer based enumerations and (b) strings based enumerations. Integer based enumerations usually start with `1`. If appropriate the value set of an enumeration is announced by the defining side (e.g. client or server) and transmitted to the other side during the initialize handshake.
As an example, consider a `printSymbol` request that uses a `PrintFormat` enumeration. The client could announce its supported printing formats via `printing.format` property:
@ -233,7 +233,7 @@ print: {
To support the evolution of enumerations the using side of an enumeration shouldn't fail on an enumeration value it doesn't know. It should simply ignore it as a value it can use and try to do its best to preserve the value on round trips. Lets look at the `PrintFormat` enumeration as an example again: if in a future version of the protocol an additional `"html"` format is added and is now announced by a client, an (older) server not knowing about the value should not fail but simply ignore the value as a usable printing format.
#### <a href="#abstractMessage" name="abstractMessage" class="anchor"> Abstract Message </a>
#### <a href="#abstractMessage" name="abstractMessage" class="anchor">Abstract Message</a>
A general message as defined by JSON-RPC. The language server protocol always uses "2.0" as the `jsonrpc` version.
@ -244,7 +244,7 @@ interface Message {
jsonrpc: string;
}
```
#### <a href="#requestMessage" name="requestMessage" class="anchor"> Request Message </a>
#### <a href="#requestMessage" name="requestMessage" class="anchor">Request Message</a>
A request message to describe a request between the client and the server. Every processed request must send a response back to the sender of the request.
@ -268,7 +268,7 @@ interface RequestMessage extends Message {
}
```
#### <a href="#responseMessage" name="responseMessage" class="anchor"> Response Message </a>
#### <a href="#responseMessage" name="responseMessage" class="anchor">Response Message</a>
A Response Message sent as a result of a request. If a request doesn't provide a result value the receiver of a request still needs to return a response message to conform to the JSON-RPC specification. The result property of the ResponseMessage should be set to `null` in this case to signal a successful request.
@ -395,7 +395,7 @@ export namespace ErrorCodes {
```
To avoid conflicts with the error codes taken by the language service protocol, other implementers of the base protocol must use error codes outside the range defined by `lspReservedErrorRangeStart` and `lspReservedErrorRangeEnd`.
#### <a href="#notificationMessage" name="notificationMessage" class="anchor"> Notification Message </a>
#### <a href="#notificationMessage" name="notificationMessage" class="anchor">Notification Message</a>
A notification message. A processed notification message must not send a response back. They work like events.
@ -413,11 +413,11 @@ interface NotificationMessage extends Message {
}
```
#### <a href="#dollarRequests" name="dollarRequests" class="anchor"> $ Notifications and Requests </a>
#### <a href="#dollarRequests" name="dollarRequests" class="anchor">$ Notifications and Requests</a>
Notification and requests whose methods start with '\$/' are messages which are protocol implementation dependent and might not be implementable in all clients or servers. For example, if the server implementation uses a single threaded synchronous programming language then there is little a server can do to react to a `$/cancelRequest` notification. If a server or client receives notifications starting with '\$/' it is free to ignore the notification. If a server or client receives a request starting with '\$/' it must error the request with error code `MethodNotFound` (e.g. `-32601`).
#### <a href="#cancelRequest" name="cancelRequest" class="anchor"> Cancellation Support (:arrow_right: :arrow_left:)</a>
#### <a href="#cancelRequest" name="cancelRequest" class="anchor">Cancellation Support (:arrow_right: :arrow_left:)</a>
The base protocol offers support for request cancellation. To cancel a request, a notification message with the following properties is sent:
@ -436,7 +436,7 @@ interface CancelParams {
A request that got canceled still needs to return from the server and send a response back. It can not be left open / hanging. This is in line with the JSON-RPC protocol that requires that every request sends a response back. In addition it allows for returning partial results on cancel. If the request returns an error response on cancellation it is advised to set the error code to `ErrorCodes.RequestCancelled`.
#### <a href="#progress" name="progress" class="anchor"> Progress Support (:arrow_right: :arrow_left:)</a>
#### <a href="#progress" name="progress" class="anchor">Progress Support (:arrow_right: :arrow_left:)</a>
The base protocol also offers support to report progress in a generic fashion. This mechanism can be used to report any kind of progress including [work done progress](#workDoneProgress) (usually used to report progress in the user interface using a progress bar) and partial result progress to support streaming of results.
@ -466,11 +466,11 @@ interface ProgressParams<T> {
Progress is reported against a token. The token is different than the request ID which allows to report progress out of band and also for notification.
#### <a href="#workDoneProgress" name="workDoneProgress" class="anchor"> Work Done Progress </a>
#### <a href="#workDoneProgress" name="workDoneProgress" class="anchor">Work Done Progress</a>
Work done progress is reported using the generic [`$/progress`](#progress) notification. The value payload of a work done progress notification can be of three different forms.
##### <a href="#workDoneProgressBegin" name="workDoneProgressBegin" class="anchor"> Work Done Progress Begin </a>
##### <a href="#workDoneProgressBegin" name="workDoneProgressBegin" class="anchor">Work Done Progress Begin</a>
To start progress reporting a `$/progress` notification with the following payload must be sent:
@ -514,7 +514,7 @@ export interface WorkDoneProgressBegin {
}
```
##### <a href="#workDoneProgressReport" name="workDoneProgressReport" class="anchor"> Work Done Progress Report </a>
##### <a href="#workDoneProgressReport" name="workDoneProgressReport" class="anchor">Work Done Progress Report</a>
Reporting progress is done using the following payload:
@ -552,7 +552,7 @@ export interface WorkDoneProgressReport {
}
```
##### <a href="#workDoneProgressEnd" name="workDoneProgressEnd" class="anchor"> Work Done Progress End </a>
##### <a href="#workDoneProgressEnd" name="workDoneProgressEnd" class="anchor">Work Done Progress End</a>
Signaling the end of a progress reporting is done using the following payload:
@ -568,14 +568,14 @@ export interface WorkDoneProgressEnd {
}
```
##### <a href="#initiatingWorkDoneProgress" name="initiatingWorkDoneProgress" class="anchor"> Initiating Work Done Progress </a>
##### <a href="#initiatingWorkDoneProgress" name="initiatingWorkDoneProgress" class="anchor">Initiating Work Done Progress</a>
Work Done progress can be initiated in two different ways:
1. by the sender of a request (mostly clients) using the predefined `workDoneToken` property in the requests parameter literal. The document will refer to this kind of progress as client initiated progress.
1. by a server using the request `window/workDoneProgress/create`. The document will refer to this kind of progress as server initiated progress.
###### <a href="#clientInitiatedProgress" name="clientInitiatedProgress" class="anchor">Client Initiated Progress </a>
###### <a href="#clientInitiatedProgress" name="clientInitiatedProgress" class="anchor">Client Initiated Progress</a>
Consider a client sending a `build/deploy` request to a server that can compile and build applications and the client accepts work done progress reporting on that request. To signal this to the server, the client would add a `workDoneToken` property to the reference request parameters:
@ -644,7 +644,7 @@ export interface WorkDoneProgressOptions {
workDoneProgress?: boolean;
}
```
###### <a href="#serverInitiatedProgress" name="serverInitiatedProgress" class="anchor">Server Initiated Progress </a>
###### <a href="#serverInitiatedProgress" name="serverInitiatedProgress" class="anchor">Server Initiated Progress</a>
Servers can also initiate progress reporting using the `window/workDoneProgress/create` request. This is useful if the server needs to report progress outside of a request (for example, the server needs to re-index a database). The token can then be used to report progress using the same notifications used as for client initiated progress. The token provided in the create request should only be used once (e.g. only one begin, many report and one end notification should be sent to it).
@ -665,7 +665,7 @@ To keep the protocol backwards compatible servers are only allowed to use `windo
{% include types/traceValue.md %}
## <a href="#lifecycle" name="lifecycle" class="anchor"> Lifecycle Messages </a>
## <a href="#lifecycle" name="lifecycle" class="anchor">Lifecycle Messages</a>
The current protocol specification defines that the lifecycle of a server is managed by the client (e.g. a tool like VS Code or Emacs). It is up to the client to decide when to start (process-wise) and when to shutdown a server.

4
_specifications/lsif/0.4.0/specification.md
View file

@ -460,7 +460,7 @@ In the above example, there will be three reference results
For Typescript, method references are recorded at their most abstract declaration and if methods are merged (`B#foo`), they are combined using a reference result pointing to other results.
### <a href="#references" name="implementation" class="anchor">Request: `textDocument/implementation`</a>
### <a href="#references" name="references" class="anchor">Request: `textDocument/implementation`</a>
Supporting a `textDocument/implementation` request is done reusing what we implemented for a `textDocument/references` request. In most cases, the `textDocument/implementation` returns the declaration values of the reference result that a symbol declaration points to. For cases where the result differs, the LSIF provides an `ImplementationResult`. To nest implementation results the `item` edge supports a `property` value `"implementationResults"`.
@ -1064,7 +1064,7 @@ The following emitting constraints (some of which have already been mentioned in
- after a document end event has been emitted only result sets, reference or implementation results emitted through that document can be referenced in edges. It is for example not allowed to reference ranges or result ranges from that document. This also includes adding monikers to ranges or result sets. The document data so to speak can not be altered anymore.
- if ranges point to result sets and monikers are emitted, they must be emitted on the result set and can't be emitted on individual ranges.
## <a href="#additionalInformation" name="additionalInformation" class="anchor">Additional Information </a>
## <a href="#additionalInformation" name="additionalInformation" class="anchor">Additional Information</a>
### <a href="#tools" name="tools" class="anchor">Tools</a>

4
_specifications/lsif/0.5.0/specification.md
View file

@ -551,7 +551,7 @@ In the above example, there will be three reference results
For Typescript, method references are recorded at their most abstract declaration and if methods are merged (`B#foo`), they are combined using a reference result pointing to other results.
### <a href="#references" name="implementation" class="anchor">Request: `textDocument/implementation`</a>
### <a href="#references" name="references" class="anchor">Request: `textDocument/implementation`</a>
Supporting a `textDocument/implementation` request is done reusing what we implemented for a `textDocument/references` request. In most cases, the `textDocument/implementation` returns the declaration values of the reference result that a symbol declaration points to. For cases where the result differs, the LSIF provides an `ImplementationResult`. To nest implementation results the `item` edge supports a `property` value `"implementationResults"`.
@ -1476,7 +1476,7 @@ The following emitting constraints (some of which have already been mentioned in
- after a document end event has been emitted only result sets, reference or implementation results emitted through that document can be referenced in edges. It is for example not allowed to reference ranges or result ranges from that document. This also includes adding monikers to ranges or result sets. The document data so to speak can not be altered anymore.
- if ranges point to result sets and monikers are emitted, they must be emitted on the result set and can't be emitted on individual ranges.
## <a href="#additionalInformation" name="additionalInformation" class="anchor">Additional Information </a>
## <a href="#additionalInformation" name="additionalInformation" class="anchor">Additional Information</a>
### <a href="#tools" name="tools" class="anchor">Tools</a>

4
_specifications/lsif/0.6.0/specification.md
View file

@ -557,7 +557,7 @@ In the above example, there will be three reference results
For Typescript, method references are recorded at their most abstract declaration and if methods are merged (`B#foo`), they are combined using a reference result pointing to other results.
### <a href="#references" name="implementation" class="anchor">Request: `textDocument/implementation`</a>
### <a href="#references" name="references" class="anchor">Request: `textDocument/implementation`</a>
Supporting a `textDocument/implementation` request is done reusing what we implemented for a `textDocument/references` request. In most cases, the `textDocument/implementation` returns the declaration values of the reference result that a symbol declaration points to. For cases where the result differs, the LSIF provides an `ImplementationResult`. To nest implementation results the `item` edge supports a `property` value `"implementationResults"`.
@ -1539,7 +1539,7 @@ The following emitting constraints (some of which have already been mentioned in
- if ranges point to result sets and monikers are emitted, they must be emitted on the result set and can't be emitted on individual ranges.
- if a range is references in items edge the range must have been attached to a document using the contains edge. This ensures that target document of a range is known. (@since 0.6.0)
## <a href="#additionalInformation" name="additionalInformation" class="anchor">Additional Information </a>
## <a href="#additionalInformation" name="additionalInformation" class="anchor">Additional Information</a>
### <a href="#tools" name="tools" class="anchor">Tools</a>

2
_specifications/lsp/3.17/language/inlayHint.md
View file

@ -113,7 +113,7 @@ export interface InlayHint {
/**
* The position of this hint.
*
*
* If multiple hints have the same position, they will be shown in the order
* they appear in the response.
*/

2
_specifications/lsp/3.17/language/moniker.md
View file

@ -159,4 +159,4 @@ export interface Moniker {
##### Notes
Server implementations of this method should ensure that the moniker calculation matches to those used in the corresponding LSIF implementation to ensure symbols can be associated correctly across IDE sessions and LSIF indexes.
Server implementations of this method should ensure that the moniker calculation matches to those used in the corresponding LSIF implementation to ensure symbols can be associated correctly across IDE sessions and LSIF indexes.

36
_specifications/lsp/3.17/specification.md
View file

@ -19,7 +19,7 @@ This document describes the 3.17.x version of the language server protocol. An i
**Note:** edits to this specification can be made via a pull request against this markdown [document](https://github.com/Microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/specification.md).
## <a href="#whatIsNew" name="whatIsNew" class="anchor"> What's new in 3.17 </a>
## <a href="#whatIsNew" name="whatIsNew" class="anchor">What's new in 3.17</a>
All new 3.17 features are tagged with a corresponding since version 3.17 text or in JSDoc using `@since 3.17.0` annotation. Major new feature are: type hierarchy, inline values, inlay hints, notebook document support and a meta model that describes the 3.17 LSP version.
@ -27,12 +27,12 @@ A detailed list of the changes can be found in the [change log](#version_3_17_0)
The version of the specification is used to group features into a new specification release and to refer to their first appearance. Features in the spec are kept compatible using so called capability flags which are exchanged between the client and the server during initialization.
## <a href="#baseProtocol" name="baseProtocol" class="anchor"> Base Protocol </a>
## <a href="#baseProtocol" name="baseProtocol" class="anchor">Base Protocol</a>
The base protocol consists of a header and a content part (comparable to HTTP). The header and content part are
separated by a '\r\n'.
### <a href="#headerPart" name="headerPart" class="anchor"> Header Part </a>
### <a href="#headerPart" name="headerPart" class="anchor">Header Part</a>
The header part consists of header fields. Each header field is comprised of a name and a value, separated by ': ' (a colon and a space). The structure of header fields conforms to the [HTTP semantic](https://tools.ietf.org/html/rfc7230#section-3.2). Each header field is terminated by '\r\n'. Considering the last header field and the overall header itself are each terminated with '\r\n', and that at least one header is mandatory, this means that two '\r\n' sequences always immediately precede the content part of a message.
@ -46,7 +46,7 @@ Currently the following header fields are supported:
The header part is encoded using the 'ascii' encoding. This includes the '\r\n' separating the header and content part.
### <a href="#contentPart" name="contentPart" class="anchor"> Content Part </a>
### <a href="#contentPart" name="contentPart" class="anchor">Content Part</a>
Contains the actual content of the message. The content part of a message uses [JSON-RPC](http://www.jsonrpc.org/) to describe requests, responses and notifications. The content part is encoded using the charset provided in the Content-Type field. It defaults to `utf-8`, which is the only encoding supported right now. If a server or client receives a header with a different encoding than `utf-8` it should respond with an error.
@ -70,7 +70,7 @@ Content-Length: ...\r\n
The following TypeScript definitions describe the base [JSON-RPC protocol](http://www.jsonrpc.org/specification):
#### <a href="#baseTypes" name="baseTypes" class="anchor"> Base Types </a>
#### <a href="#baseTypes" name="baseTypes" class="anchor">Base Types</a>
The protocol uses the following definitions for integers, unsigned integers, decimal numbers, objects and arrays:
@ -139,7 +139,7 @@ export type LSPObject = { [key: string]: LSPAny };
export type LSPArray = LSPAny[];
```
#### <a href="#abstractMessage" name="abstractMessage" class="anchor"> Abstract Message </a>
#### <a href="#abstractMessage" name="abstractMessage" class="anchor">Abstract Message</a>
A general message as defined by JSON-RPC. The language server protocol always uses "2.0" as the `jsonrpc` version.
@ -150,7 +150,7 @@ interface Message {
jsonrpc: string;
}
```
#### <a href="#requestMessage" name="requestMessage" class="anchor"> Request Message </a>
#### <a href="#requestMessage" name="requestMessage" class="anchor">Request Message</a>
A request message to describe a request between the client and the server. Every processed request must send a response back to the sender of the request.
@ -174,7 +174,7 @@ interface RequestMessage extends Message {
}
```
#### <a href="#responseMessage" name="responseMessage" class="anchor"> Response Message </a>
#### <a href="#responseMessage" name="responseMessage" class="anchor">Response Message</a>
A Response Message sent as a result of a request. If a request doesn't provide a result value the receiver of a request still needs to return a response message to conform to the JSON-RPC specification. The result property of the ResponseMessage should be set to `null` in this case to signal a successful request.
@ -315,7 +315,7 @@ export namespace ErrorCodes {
export const lspReservedErrorRangeEnd: integer = -32800;
}
```
#### <a href="#notificationMessage" name="notificationMessage" class="anchor"> Notification Message </a>
#### <a href="#notificationMessage" name="notificationMessage" class="anchor">Notification Message</a>
A notification message. A processed notification message must not send a response back. They work like events.
@ -333,11 +333,11 @@ interface NotificationMessage extends Message {
}
```
#### <a href="#dollarRequests" name="dollarRequests" class="anchor"> $ Notifications and Requests </a>
#### <a href="#dollarRequests" name="dollarRequests" class="anchor">$ Notifications and Requests</a>
Notifications and requests whose methods start with '\$/' are messages which are protocol implementation dependent and might not be implementable in all clients or servers. For example if the server implementation uses a single threaded synchronous programming language then there is little a server can do to react to a `$/cancelRequest` notification. If a server or client receives notifications starting with '\$/' it is free to ignore the notification. If a server or client receives a request starting with '\$/' it must error the request with error code `MethodNotFound` (e.g. `-32601`).
#### <a href="#cancelRequest" name="cancelRequest" class="anchor"> Cancellation Support (:arrow_right: :arrow_left:)</a>
#### <a href="#cancelRequest" name="cancelRequest" class="anchor">Cancellation Support (:arrow_right: :arrow_left:)</a>
The base protocol offers support for request cancellation. To cancel a request, a notification message with the following properties is sent:
@ -356,7 +356,7 @@ interface CancelParams {
A request that got canceled still needs to return from the server and send a response back. It can not be left open / hanging. This is in line with the JSON-RPC protocol that requires that every request sends a response back. In addition it allows for returning partial results on cancel. If the request returns an error response on cancellation it is advised to set the error code to `ErrorCodes.RequestCancelled`.
#### <a href="#progress" name="progress" class="anchor"> Progress Support (:arrow_right: :arrow_left:)</a>
#### <a href="#progress" name="progress" class="anchor">Progress Support (:arrow_right: :arrow_left:)</a>
> *Since version 3.15.0*
@ -388,7 +388,7 @@ interface ProgressParams<T> {
Progress is reported against a token. The token is different than the request ID which allows to report progress out of band and also for notification.
## <a href="#languageServerProtocol" name="languageServerProtocol" class="anchor"> Language Server Protocol </a>
## <a href="#languageServerProtocol" name="languageServerProtocol" class="anchor">Language Server Protocol</a>
The language server protocol defines a set of JSON-RPC request, response and notification messages which are exchanged using the above base protocol. This section starts describing the basic JSON structures used in the protocol. The document uses TypeScript interfaces in strict mode to describe these. This means for example that a `null` value has to be explicitly listed and that a mandatory property must be listed even if a falsy value might exist. Based on the basic JSON structures, the actual requests with their responses and the notifications are described.
@ -415,19 +415,19 @@ In general, the language server protocol supports JSON-RPC messages, however the
The protocol currently assumes that one server serves one tool. There is currently no support in the protocol to share one server between different tools. Such sharing would require additional protocol e.g. to lock a document to support concurrent editing.
### <a href="#capabilities" name= "capabilities" class="anchor"> Capabilities </a>
### <a href="#capabilities" name="capabilities" class="anchor">Capabilities</a>
Not every language server can support all features defined by the protocol. LSP therefore provides ‘capabilities’. A capability groups a set of language features. A development tool and the language server announce their supported features using capabilities. As an example, a server announces that it can handle the `textDocument/hover` request, but it might not handle the `workspace/symbol` request. Similarly, a development tool announces its ability to provide `about to save` notifications before a document is saved, so that a server can compute textual edits to format the edited document before it is saved.
The set of capabilities is exchanged between the client and server during the [initialize](#initialize) request.
### <a href="#messageOrdering" name= "messageOrdering" class="anchor"> Request, Notification and Response Ordering </a>
### <a href="#messageOrdering" name="messageOrdering" class="anchor">Request, Notification and Response Ordering</a>
Responses to requests should be sent in roughly the same order as the requests appear on the server or client side. So for example if a server receives a `textDocument/completion` request and then a `textDocument/signatureHelp` request it will usually first return the response for the `textDocument/completion` and then the response for `textDocument/signatureHelp`.
However, the server may decide to use a parallel execution strategy and may wish to return responses in a different order than the requests were received. The server may do so as long as this reordering doesn't affect the correctness of the responses. For example, reordering the result of `textDocument/completion` and `textDocument/signatureHelp` is allowed, as each of these requests usually won't affect the output of the other. On the other hand, the server most likely should not reorder `textDocument/definition` and `textDocument/rename` requests, since executing the latter may affect the result of the former.
### <a href="#messageDocumentation" name= "messageDocumentation" class="anchor"> Message Documentation </a>
### <a href="#messageDocumentation" name="messageDocumentation" class="anchor">Message Documentation</a>
As said LSP defines a set of requests, responses and notifications. Each of those are documented using the following format:
@ -439,7 +439,7 @@ As said LSP defines a set of requests, responses and notifications. Each of thos
* a _Response_ section describing the format of the response. The result item describes the returned data in case of a success. The optional partial result item describes the returned data of a partial result notification. The error.data describes the returned data in case of an error. Please remember that in case of a failure the response already contains an error.code and an error.message field. These fields are only specified if the protocol forces the use of certain error codes or messages. In cases where the server can decide on these values freely they aren't listed here.
### <a href="#basicJsonStructures" name="basicJsonStructures" class="anchor"> Basic JSON Structures </a>
### <a href="#basicJsonStructures" name="basicJsonStructures" class="anchor">Basic JSON Structures</a>
There are quite some JSON structures that are shared between different requests and notifications. Their structure and capabilities are documented in this section.
@ -472,7 +472,7 @@ There are quite some JSON structures that are shared between different requests
{% include_relative types/partialResultParams.md %}
{% include types/traceValue.md %}
### <a href="#lifeCycleMessages" name="lifeCycleMessages" class="anchor"> Server lifecycle </a>
### <a href="#lifeCycleMessages" name="lifeCycleMessages" class="anchor">Server lifecycle</a>
The current protocol specification defines that the lifecycle of a server is managed by the client (e.g. a tool like VS Code or Emacs). It is up to the client to decide when to start (process-wise) and when to shutdown a server.

2
_specifications/lsp/3.17/textDocument/didClose.md
View file

@ -23,4 +23,4 @@ interface DidCloseTextDocumentParams {
*/
textDocument: TextDocumentIdentifier;
}
```
```

2
_specifications/lsp/3.17/textDocument/didOpen.md
View file

@ -25,4 +25,4 @@ interface DidOpenTextDocumentParams {
*/
textDocument: TextDocumentItem;
}
```
```

4
_specifications/lsp/3.17/types/command.md
View file

@ -1,4 +1,4 @@
#### <a href="#command" name="command" class="anchor"> Command </a>
#### <a href="#command" name="command" class="anchor">Command</a>
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.
@ -18,4 +18,4 @@ interface Command {
*/
arguments?: LSPAny[];
}
```
```

4
_specifications/lsp/3.17/types/diagnostic.md
View file

@ -1,4 +1,4 @@
#### <a href="#diagnostic" name="diagnostic" class="anchor"> Diagnostic </a>
#### <a href="#diagnostic" name="diagnostic" class="anchor">Diagnostic</a>
Represents a diagnostic, such as a compiler error or warning. Diagnostic objects are only valid in the scope of a resource.
@ -157,4 +157,4 @@ export interface CodeDescription {
*/
href: URI;
}
```
```

4
_specifications/lsp/3.17/types/documentFilter.md
View file

@ -1,4 +1,4 @@
#### <a href="#documentFilter" name="documentFilter" class="anchor"> DocumentFilter </a>
#### <a href="#documentFilter" name="documentFilter" class="anchor">DocumentFilter</a>
A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter that applies to JSON files with name `package.json`:
```typescript
@ -45,4 +45,4 @@ A document selector is the combination of one or more document filters.
```typescript
export type DocumentSelector = DocumentFilter[];
```
```

4
_specifications/lsp/3.17/types/location.md
View file

@ -1,4 +1,4 @@
#### <a href="#location" name="location" class="anchor"> Location </a>
#### <a href="#location" name="location" class="anchor">Location</a>
Represents a location inside a resource, such as a line inside a text file.
```typescript
@ -6,4 +6,4 @@ interface Location {
uri: DocumentUri;
range: Range;
}
```
```

4
_specifications/lsp/3.17/types/locationLink.md
View file

@ -1,4 +1,4 @@
#### <a href="#locationLink" name="locationLink" class="anchor"> LocationLink </a>
#### <a href="#locationLink" name="locationLink" class="anchor">LocationLink</a>
Represents a link between a source and a target location.
@ -33,4 +33,4 @@ interface LocationLink {
*/
targetSelectionRange: Range;
}
```
```

3
_specifications/lsp/3.17/types/markupContent.md
View file

@ -1,4 +1,4 @@
#### <a href="#markupContent" name="markupContent" class="anchor"> MarkupContent </a>
#### <a href="#markupContent" name="markupContent" class="anchor">MarkupContent</a>
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](https://github.github.com/gfm/).
@ -103,4 +103,3 @@ Parser | Version | Documentation
--------------- | ------- | -------------
marked | 1.1.0 | [Marked Documentation](https://marked.js.org/)
Python-Markdown | 3.2.2 | [Python-Markdown Documentation](https://python-markdown.github.io)

4
_specifications/lsp/3.17/types/partialResultParams.md
View file

@ -1,4 +1,4 @@
#### <a href="#partialResultParams" name="partialResultParams" class="anchor"> PartialResultParams </a>
#### <a href="#partialResultParams" name="partialResultParams" class="anchor">PartialResultParams</a>
A parameter literal used to pass a partial result token.
@ -10,4 +10,4 @@ export interface PartialResultParams {
*/
partialResultToken?: ProgressToken;
}
```
```

2
_specifications/lsp/3.17/types/partialResults.md
View file

@ -1,4 +1,4 @@
#### <a href="#partialResults" name="partialResults" class="anchor"> Partial Result Progress </a>
#### <a href="#partialResults" name="partialResults" class="anchor">Partial Result Progress</a>
> *Since version 3.15.0*

2
_specifications/lsp/3.17/types/position.md
View file

@ -1,4 +1,4 @@
#### <a href="#position" name="position" class="anchor"> Position </a>
#### <a href="#position" name="position" class="anchor">Position</a>
Position in a text document expressed as zero-based line and zero-based character offset. A position is between two characters like an 'insert' cursor in an editor. Special values like for example `-1` to denote the end of a line are not supported.

2
_specifications/lsp/3.17/types/range.md
View file

@ -1,4 +1,4 @@
#### <a href="#range" name="range" class="anchor"> Range </a>
#### <a href="#range" name="range" class="anchor">Range</a>
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. If you want to specify a range that contains a line including the line ending character(s) then use an end position denoting the start of the next line. For example:
```typescript

2
_specifications/lsp/3.17/types/regexp.md
View file

@ -1,4 +1,4 @@
#### <a href="#regExp" name="regExp" class="anchor"> Regular Expressions </a>
#### <a href="#regExp" name="regExp" class="anchor">Regular Expressions</a>
Regular expression are a powerful tool and there are actual use cases for them in the language server protocol. However the downside with them is that almost every programming language has its own set of regular expression features so the specification can not simply refer to them as a regular expression. So the LSP uses a two step approach to support regular expressions:

4
_specifications/lsp/3.17/types/resourceChanges.md
View file

@ -1,4 +1,4 @@
### <a href="#resourceChanges" name="resourceChanges" class="anchor"> File Resource changes </a>
### <a href="#resourceChanges" name="resourceChanges" class="anchor">File Resource changes</a>
> New in version 3.13. Since version 3.16 file resource changes can carry an additional property `changeAnnotation` to describe the actual change in more detail. Whether a client has support for change annotations is guarded by the client capability `workspace.workspaceEdit.changeAnnotationSupport`.
@ -157,4 +157,4 @@ export interface DeleteFile {
*/
annotationId?: ChangeAnnotationIdentifier;
}
```
```

4
_specifications/lsp/3.17/types/textDocumentEdit.md
View file

@ -1,4 +1,4 @@
#### <a href="#textDocumentEdit" name="textDocumentEdit" class="anchor"> TextDocumentEdit </a>
#### <a href="#textDocumentEdit" name="textDocumentEdit" class="anchor">TextDocumentEdit</a>
> New in version 3.16: support for `AnnotatedTextEdit`. The support is guarded by the client capability `workspace.workspaceEdit.changeAnnotationSupport`. If a client doesn't signal the capability, servers shouldn't send `AnnotatedTextEdit` literals back to the client.
@ -19,4 +19,4 @@ export interface TextDocumentEdit {
*/
edits: (TextEdit | AnnotatedTextEdit)[];
}
```
```

4
_specifications/lsp/3.17/types/textDocumentIdentifier.md
View file

@ -1,4 +1,4 @@
#### <a href="#textDocumentIdentifier" name="textDocumentIdentifier" class="anchor"> TextDocumentIdentifier </a>
#### <a href="#textDocumentIdentifier" name="textDocumentIdentifier" class="anchor">TextDocumentIdentifier</a>
Text documents are identified using a URI. On the protocol level, URIs are passed as strings. The corresponding JSON structure looks like this:
```typescript
@ -8,4 +8,4 @@ interface TextDocumentIdentifier {
*/
uri: DocumentUri;
}
```
```

3
_specifications/lsp/3.17/types/textDocumentItem.md
View file

@ -1,4 +1,4 @@
#### <a href="#textDocumentItem" name="textDocumentItem" class="anchor"> TextDocumentItem </a>
#### <a href="#textDocumentItem" name="textDocumentItem" class="anchor">TextDocumentItem</a>
An item to transfer a text document from the client to the server.
@ -87,4 +87,3 @@ XML | `xml`
XSL | `xsl`
YAML | `yaml`
{: .table .table-bordered .table-responsive}

4
_specifications/lsp/3.17/types/textDocumentPositionParams.md
View file

@ -1,4 +1,4 @@
#### <a href="#textDocumentPositionParams" name="textDocumentPositionParams" class="anchor"> TextDocumentPositionParams </a>
#### <a href="#textDocumentPositionParams" name="textDocumentPositionParams" class="anchor">TextDocumentPositionParams</a>
Was `TextDocumentPosition` in 1.0 with inlined parameters.
@ -16,4 +16,4 @@ interface TextDocumentPositionParams {
*/
position: Position;
}
```
```

2
_specifications/lsp/3.17/types/textDocuments.md
View file

@ -1,4 +1,4 @@
#### <a href="#textDocuments" name="textDocuments" class="anchor"> Text Documents </a>
#### <a href="#textDocuments" name="textDocuments" class="anchor">Text Documents</a>
The current protocol is tailored for textual documents whose content can be represented as a string. There is currently no support for binary documents. A position inside a document (see Position definition below) is expressed as a zero-based line and character offset.

4
_specifications/lsp/3.17/types/textEdit.md
View file

@ -1,4 +1,4 @@
#### <a href="#textEdit" name="textEdit" class="anchor"> TextEdit & AnnotatedTextEdit </a>
#### <a href="#textEdit" name="textEdit" class="anchor">TextEdit & AnnotatedTextEdit</a>
> New in version 3.16: Support for `AnnotatedTextEdit`.
@ -78,4 +78,4 @@ export interface AnnotatedTextEdit extends TextEdit {
*/
annotationId: ChangeAnnotationIdentifier;
}
```
```

2
_specifications/lsp/3.17/types/textEditArray.md
View file

@ -1,4 +1,4 @@
#### <a href="#textEditArray" name="textEditArray" class="anchor"> TextEdit[] </a>
#### <a href="#textEditArray" name="textEditArray" class="anchor">TextEdit[]</a>
Complex text manipulations are described with an array of `TextEdit`'s or `AnnotatedTextEdit`'s, representing a single change to the document.

4
_specifications/lsp/3.17/types/versionedTextDocumentIdentifier.md
View file

@ -1,4 +1,4 @@
#### <a href="#versionedTextDocumentIdentifier" name="versionedTextDocumentIdentifier" class="anchor"> VersionedTextDocumentIdentifier </a>
#### <a href="#versionedTextDocumentIdentifier" name="versionedTextDocumentIdentifier" class="anchor">VersionedTextDocumentIdentifier</a>
An identifier to denote a specific version of a text document. This information usually flows from the client to the server.
@ -33,4 +33,4 @@ interface OptionalVersionedTextDocumentIdentifier extends TextDocumentIdentifier
*/
version: integer | null;
}
```
```

16
_specifications/lsp/3.17/types/workDoneProgress.md
View file

@ -1,10 +1,10 @@
#### <a href="#workDoneProgress" name="workDoneProgress" class="anchor"> Work Done Progress </a>
#### <a href="#workDoneProgress" name="workDoneProgress" class="anchor">Work Done Progress</a>
> *Since version 3.15.0*
Work done progress is reported using the generic [`$/progress`](#progress) notification. The value payload of a work done progress notification can be of three different forms.
##### <a href="#workDoneProgressBegin" name="workDoneProgressBegin" class="anchor"> Work Done Progress Begin </a>
##### <a href="#workDoneProgressBegin" name="workDoneProgressBegin" class="anchor">Work Done Progress Begin</a>
To start progress reporting a `$/progress` notification with the following payload must be sent:
@ -49,7 +49,7 @@ export interface WorkDoneProgressBegin {
}
```
##### <a href="#workDoneProgressReport" name="workDoneProgressReport" class="anchor"> Work Done Progress Report </a>
##### <a href="#workDoneProgressReport" name="workDoneProgressReport" class="anchor">Work Done Progress Report</a>
Reporting progress is done using the following payload:
@ -88,7 +88,7 @@ export interface WorkDoneProgressReport {
}
```
##### <a href="#workDoneProgressEnd" name="workDoneProgressEnd" class="anchor"> Work Done Progress End </a>
##### <a href="#workDoneProgressEnd" name="workDoneProgressEnd" class="anchor">Work Done Progress End</a>
Signaling the end of a progress reporting is done using the following payload:
@ -105,14 +105,14 @@ export interface WorkDoneProgressEnd {
}
```
##### <a href="#initiatingWorkDoneProgress" name="initiatingWorkDoneProgress" class="anchor"> Initiating Work Done Progress </a>
##### <a href="#initiatingWorkDoneProgress" name="initiatingWorkDoneProgress" class="anchor">Initiating Work Done Progress</a>
Work Done progress can be initiated in two different ways:
1. by the sender of a request (mostly clients) using the predefined `workDoneToken` property in the requests parameter literal. The document will refer to this kind of progress as client initiated progress.
1. by a server using the request `window/workDoneProgress/create`. The document will refer to this kind of progress as server initiated progress.
###### <a href="#clientInitiatedProgress" name="clientInitiatedProgress" class="anchor">Client Initiated Progress </a>
###### <a href="#clientInitiatedProgress" name="clientInitiatedProgress" class="anchor">Client Initiated Progress</a>
Consider a client sending a `textDocument/reference` request to a server and the client accepts work done progress reporting on that request. To signal this to the server the client would add a `workDoneToken` property to the reference request parameters. Something like this:
@ -186,7 +186,7 @@ export interface WorkDoneProgressOptions {
workDoneProgress?: boolean;
}
```
###### <a href="#serverInitiatedProgress" name="serverInitiatedProgress" class="anchor">Server Initiated Progress </a>
###### <a href="#serverInitiatedProgress" name="serverInitiatedProgress" class="anchor">Server Initiated Progress</a>
Servers can also initiate progress reporting using the `window/workDoneProgress/create` request. This is useful if the server needs to report progress outside of a request (for example the server needs to re-index a database). The token can then be used to report progress using the same notifications used as for client initiated progress. The token provided in the create request should only be used once (e.g. only one begin, many report and one end notification should be sent to it).
@ -203,4 +203,4 @@ To keep the protocol backwards compatible servers are only allowed to use `windo
*/
workDoneProgress?: boolean;
};
```
```

6
_specifications/lsp/3.17/types/workspaceEdit.md
View file

@ -1,4 +1,4 @@
#### <a href="#workspaceEdit" name="workspaceEdit" class="anchor"> WorkspaceEdit </a>
#### <a href="#workspaceEdit" name="workspaceEdit" class="anchor">WorkspaceEdit</a>
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`.
@ -47,7 +47,7 @@ export interface WorkspaceEdit {
}
```
##### <a href="#workspaceEditClientCapabilities" name="workspaceEditClientCapabilities" class="anchor"> WorkspaceEditClientCapabilities </a>
##### <a href="#workspaceEditClientCapabilities" name="workspaceEditClientCapabilities" class="anchor">WorkspaceEditClientCapabilities</a>
> New in version 3.13: `ResourceOperationKind` and `FailureHandlingKind` and the client capability `workspace.workspaceEdit.resourceOperations` as well as `workspace.workspaceEdit.failureHandling`.
@ -171,4 +171,4 @@ export namespace FailureHandlingKind {
*/
export const Undo: FailureHandlingKind = 'undo';
}
```
```

4
_specifications/lsp/3.17/window/workDoneProgressCancel.md
View file

@ -1,4 +1,4 @@
#### <a href="#window_workDoneProgress_cancel" name="window_workDoneProgress_cancel" class="anchor"> Cancel a Work Done Progress (:arrow_right:)</a>
#### <a href="#window_workDoneProgress_cancel" name="window_workDoneProgress_cancel" class="anchor">Cancel a Work Done Progress (:arrow_right:)</a>
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 progress need not be marked as `cancellable` to be cancelled and a client may cancel a progress for any number of reasons: in case of error, reloading a workspace etc.
@ -14,4 +14,4 @@ export interface WorkDoneProgressCancelParams {
*/
token: ProgressToken;
}
```
```

2
_specifications/lsp/3.17/window/workDoneProgressCreate.md
View file

@ -1,4 +1,4 @@
#### <a href="#window_workDoneProgress_create" name="window_workDoneProgress_create" class="anchor"> Create Work Done Progress (:arrow_right_hook:)</a>
#### <a href="#window_workDoneProgress_create" name="window_workDoneProgress_create" class="anchor">Create Work Done Progress (:arrow_right_hook:)</a>
The `window/workDoneProgress/create` request is sent from the server to the client to ask the client to create a work done progress.

4
_specifications/lsp/3.18/language/codeAction.md
View file

@ -119,7 +119,7 @@ export interface CodeActionClientCapabilities {
* The tags supported by the client.
*/
valueSet: CodeActionTag[];
};
};
}
```
@ -374,7 +374,7 @@ export interface CodeActionContext {
* for the given range. There is no guarantee that these accurately reflect
* the error state of the resource. The primary parameter
* to compute code actions is the provided range.
*
*
* Note that the client should check the `textDocument.diagnostic.markupMessageSupport`
* server capability before sending diagnostics with markup messages to a server.
* Diagnostics with markup messages should be excluded for servers that don't support

4
_specifications/lsp/3.18/language/foldingRange.md
View file

@ -217,7 +217,7 @@ export interface FoldingRangeWorkspaceClientCapabilities {
* folding ranges currently shown. It should be used with absolute care and is
* useful for situation where a server, for example, detects a project wide
* change that requires such a calculation.
*
*
* @since 3.18.0
* @proposed
*/
@ -233,4 +233,4 @@ _Request_:
_Response_:
* result: void
* error: code and message set in case an exception happens during the 'workspace/foldingRange/refresh' request
* error: code and message set in case an exception happens during the 'workspace/foldingRange/refresh' request

2
_specifications/lsp/3.18/language/pullDiagnostics.md
View file

@ -33,7 +33,7 @@ export interface DiagnosticClientCapabilities {
/**
* Whether the client supports `MarkupContent` in diagnostic messages.
*
*
* @since 3.18.0
* @proposed
*/

36
_specifications/lsp/3.18/specification.md
View file

@ -12,7 +12,7 @@ This document describes the upcoming 3.18.x version of the language server proto
**Note:** edits to this specification can be made via a pull request against this markdown [document](https://github.com/Microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.18/specification.md).
## <a href="#whatIsNew" name="whatIsNew" class="anchor"> What's new in 3.18 </a>
## <a href="#whatIsNew" name="whatIsNew" class="anchor">What's new in 3.18</a>
All new 3.18 features are tagged with a corresponding since version 3.18 text or in JSDoc using `@since 3.18.0` annotation.
@ -20,12 +20,12 @@ A detailed list of the changes can be found in the [change log](#version_3_18_0)
The version of the specification is used to group features into a new specification release and to refer to their first appearance. Features in the spec are kept compatible using so called capability flags which are exchanged between the client and the server during initialization.
## <a href="#baseProtocol" name="baseProtocol" class="anchor"> Base Protocol </a>
## <a href="#baseProtocol" name="baseProtocol" class="anchor">Base Protocol</a>
The base protocol consists of a header and a content part (comparable to HTTP). The header and content part are
separated by a '\r\n'.
### <a href="#headerPart" name="headerPart" class="anchor"> Header Part </a>
### <a href="#headerPart" name="headerPart" class="anchor">Header Part</a>
The header part consists of header fields. Each header field is comprised of a name and a value, separated by ': ' (a colon and a space). The structure of header fields conforms to the [HTTP semantic](https://tools.ietf.org/html/rfc7230#section-3.2). Each header field is terminated by '\r\n'. Considering the last header field and the overall header itself are each terminated with '\r\n', and that at least one header is mandatory, this means that two '\r\n' sequences always immediately precede the content part of a message.
@ -39,7 +39,7 @@ Currently the following header fields are supported:
The header part is encoded using the 'ascii' encoding. This includes the '\r\n' separating the header and content part.
### <a href="#contentPart" name="contentPart" class="anchor"> Content Part </a>
### <a href="#contentPart" name="contentPart" class="anchor">Content Part</a>
Contains the actual content of the message. The content part of a message uses [JSON-RPC 2.0](https://www.jsonrpc.org/specification) to describe requests, responses and notifications. The content part is encoded using the charset provided in the Content-Type field. It defaults to `utf-8`, which is the only encoding supported right now. If a server or client receives a header with a different encoding than `utf-8` it should respond with an error.
@ -65,7 +65,7 @@ The protocol uses request, response, and notification objects as specified in th
The following TypeScript definitions describe the base JSON-RPC protocol:
#### <a href="#baseTypes" name="baseTypes" class="anchor"> Base Types </a>
#### <a href="#baseTypes" name="baseTypes" class="anchor">Base Types</a>
The protocol uses the following definitions for integers, unsigned integers, decimal numbers, objects and arrays:
@ -134,7 +134,7 @@ export type LSPObject = { [key: string]: LSPAny };
export type LSPArray = LSPAny[];
```
#### <a href="#abstractMessage" name="abstractMessage" class="anchor"> Abstract Message </a>
#### <a href="#abstractMessage" name="abstractMessage" class="anchor">Abstract Message</a>
A general message as defined by JSON-RPC. The language server protocol always uses "2.0" as the `jsonrpc` version.
@ -145,7 +145,7 @@ interface Message {
jsonrpc: string;
}
```
#### <a href="#requestMessage" name="requestMessage" class="anchor"> Request Message </a>
#### <a href="#requestMessage" name="requestMessage" class="anchor">Request Message</a>
A request message to describe a request between the client and the server. Every processed request must send a response back to the sender of the request.
@ -169,7 +169,7 @@ interface RequestMessage extends Message {
}
```
#### <a href="#responseMessage" name="responseMessage" class="anchor"> Response Message </a>
#### <a href="#responseMessage" name="responseMessage" class="anchor">Response Message</a>
A Response Message sent as a result of a request. If a request doesn't provide a result value the receiver of a request still needs to return a response message to conform to the JSON-RPC specification. The result property of the ResponseMessage should be set to `null` in this case to signal a successful request.
@ -310,7 +310,7 @@ export namespace ErrorCodes {
export const lspReservedErrorRangeEnd: integer = -32800;
}
```
#### <a href="#notificationMessage" name="notificationMessage" class="anchor"> Notification Message </a>
#### <a href="#notificationMessage" name="notificationMessage" class="anchor">Notification Message</a>
A notification message. A processed notification message must not send a response back. They work like events.
@ -328,11 +328,11 @@ interface NotificationMessage extends Message {
}
```
#### <a href="#dollarRequests" name="dollarRequests" class="anchor"> $ Notifications and Requests </a>
#### <a href="#dollarRequests" name="dollarRequests" class="anchor">$ Notifications and Requests</a>
Notifications and requests whose methods start with '\$/' are messages which are protocol implementation dependent and might not be implementable in all clients or servers. For example if the server implementation uses a single threaded synchronous programming language then there is little a server can do to react to a `$/cancelRequest` notification. If a server or client receives notifications starting with '\$/' it is free to ignore the notification. If a server or client receives a request starting with '\$/' it must error the request with error code `MethodNotFound` (e.g. `-32601`).
#### <a href="#cancelRequest" name="cancelRequest" class="anchor"> Cancellation Support (:arrow_right: :arrow_left:)</a>
#### <a href="#cancelRequest" name="cancelRequest" class="anchor">Cancellation Support (:arrow_right: :arrow_left:)</a>
The base protocol offers support for request cancellation. To cancel a request, a notification message with the following properties is sent:
@ -351,7 +351,7 @@ interface CancelParams {
A request that got canceled still needs to return from the server and send a response back. It can not be left open / hanging. This is in line with the JSON-RPC protocol that requires that every request sends a response back. In addition, it allows for returning partial results on cancel. If the request returns an error response on cancellation it is advised to set the error code to `ErrorCodes.RequestCancelled`.
#### <a href="#progress" name="progress" class="anchor"> Progress Support (:arrow_right: :arrow_left:)</a>
#### <a href="#progress" name="progress" class="anchor">Progress Support (:arrow_right: :arrow_left:)</a>
> *Since version 3.15.0*
@ -383,7 +383,7 @@ interface ProgressParams<T> {
Progress is reported against a token. The token is different than the request ID which allows to report progress out of band and also for notification.
## <a href="#languageServerProtocol" name="languageServerProtocol" class="anchor"> Language Server Protocol </a>
## <a href="#languageServerProtocol" name="languageServerProtocol" class="anchor">Language Server Protocol</a>
The language server protocol defines a set of JSON-RPC request, response and notification messages which are exchanged using the above base protocol. This section starts describing the basic JSON structures used in the protocol. The document uses TypeScript interfaces in strict mode to describe these. This means, for example, that a `null` value has to be explicitly listed and that a mandatory property must be listed even if a falsy value might exist. Based on the basic JSON structures, the actual requests with their responses and the notifications are described.
@ -410,19 +410,19 @@ In general, the language server protocol supports JSON-RPC messages, however the
The protocol currently assumes that one server serves one tool. There is currently no support in the protocol to share one server between different tools. Such sharing would require additional protocol e.g. to lock a document to support concurrent editing.
### <a href="#capabilities" name= "capabilities" class="anchor"> Capabilities </a>
### <a href="#capabilities" name="capabilities" class="anchor">Capabilities</a>
Not every language server can support all features defined by the protocol. LSP therefore provides ‘capabilities’. A capability groups a set of language features. A development tool and the language server announce their supported features using capabilities. As an example, a server announces that it can handle the `textDocument/hover` request, but it might not handle the `workspace/symbol` request. Similarly, a development tool announces its ability to provide `about to save` notifications before a document is saved, so that a server can compute textual edits to format the edited document before it is saved.
The set of capabilities is exchanged between the client and server during the [initialize](#initialize) request.
### <a href="#messageOrdering" name= "messageOrdering" class="anchor"> Request, Notification and Response Ordering </a>
### <a href="#messageOrdering" name="messageOrdering" class="anchor">Request, Notification and Response Ordering</a>
Responses to requests should be sent in roughly the same order as the requests appear on the server or client side. So, for example, if a server receives a `textDocument/completion` request and then a `textDocument/signatureHelp` request it will usually first return the response for the `textDocument/completion` and then the response for `textDocument/signatureHelp`.
However, the server may decide to use a parallel execution strategy and may wish to return responses in a different order than the requests were received. The server may do so as long as this reordering doesn't affect the correctness of the responses. For example, reordering the result of `textDocument/completion` and `textDocument/signatureHelp` is allowed, as each of these requests usually won't affect the output of the other. On the other hand, the server most likely should not reorder `textDocument/definition` and `textDocument/rename` requests, since executing the latter may affect the result of the former.
### <a href="#messageDocumentation" name= "messageDocumentation" class="anchor"> Message Documentation </a>
### <a href="#messageDocumentation" name="messageDocumentation" class="anchor">Message Documentation</a>
As said, LSP defines a set of requests, responses and notifications. Each of those are documented using the following format:
@ -434,7 +434,7 @@ As said, LSP defines a set of requests, responses and notifications. Each of tho
* a _Response_ section describing the format of the response. The result item describes the returned data in case of a success. The optional partial result item describes the returned data of a partial result notification. The error.data describes the returned data in case of an error. Please remember that in case of a failure the response already contains an error.code and an error.message field. These fields are only specified if the protocol forces the use of certain error codes or messages. In cases where the server can decide on these values freely they aren't listed here.
### <a href="#basicJsonStructures" name="basicJsonStructures" class="anchor"> Basic JSON Structures </a>
### <a href="#basicJsonStructures" name="basicJsonStructures" class="anchor">Basic JSON Structures</a>
There are quite some JSON structures that are shared between different requests and notifications. Their structure and capabilities are documented in this section.
@ -469,7 +469,7 @@ There are quite some JSON structures that are shared between different requests
{% include_relative types/partialResultParams.md %}
{% include types/traceValue.md %}
### <a href="#lifeCycleMessages" name="lifeCycleMessages" class="anchor"> Server lifecycle </a>
### <a href="#lifeCycleMessages" name="lifeCycleMessages" class="anchor">Server lifecycle</a>
The current protocol specification defines that the lifecycle of a server is managed by the client (e.g. a tool like VS Code or Emacs). It is up to the client to decide when to start (process-wise) and when to shutdown a server.

2
_specifications/lsp/3.18/textDocument/didClose.md
View file

@ -23,4 +23,4 @@ interface DidCloseTextDocumentParams {
*/
textDocument: TextDocumentIdentifier;
}
```
```

2
_specifications/lsp/3.18/textDocument/didOpen.md
View file

@ -25,4 +25,4 @@ interface DidOpenTextDocumentParams {
*/
textDocument: TextDocumentItem;
}
```
```

4
_specifications/lsp/3.18/types/command.md
View file

@ -1,4 +1,4 @@
#### <a href="#command" name="command" class="anchor"> Command </a>
#### <a href="#command" name="command" class="anchor">Command</a>
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 provide the corresponding capabilities. Alternatively, the tool extension code could handle the command. The protocol currently doesn't specify a set of well-known commands.
@ -25,4 +25,4 @@ interface Command {
*/
arguments?: LSPAny[];
}
```
```

2
_specifications/lsp/3.18/types/diagnostic.md
View file

@ -1,4 +1,4 @@
#### <a href="#diagnostic" name="diagnostic" class="anchor"> Diagnostic </a>
#### <a href="#diagnostic" name="diagnostic" class="anchor">Diagnostic</a>
- New in version 3.18: support for markup content in diagnostic messages. The support is guarded by the
client capability `textDocument.diagnostic.markupMessageSupport`. If a client doesn't signal the capability,

2
_specifications/lsp/3.18/types/documentFilter.md
View file

@ -1,4 +1,4 @@
#### <a href="#documentFilter" name="documentFilter" class="anchor"> DocumentFilter </a>
#### <a href="#documentFilter" name="documentFilter" class="anchor">DocumentFilter</a>
A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter that applies to JSON files with name `package.json`:
```typescript

4
_specifications/lsp/3.18/types/location.md
View file

@ -1,4 +1,4 @@
#### <a href="#location" name="location" class="anchor"> Location </a>
#### <a href="#location" name="location" class="anchor">Location</a>
Represents a location inside a resource, such as a line inside a text file.
```typescript
@ -6,4 +6,4 @@ interface Location {
uri: DocumentUri;
range: Range;
}
```
```

2
_specifications/lsp/3.18/types/locationLink.md
View file

@ -1,4 +1,4 @@
#### <a href="#locationLink" name="locationLink" class="anchor"> LocationLink </a>
#### <a href="#locationLink" name="locationLink" class="anchor">LocationLink</a>
Represents a link between a source and a target location.

3
_specifications/lsp/3.18/types/markupContent.md
View file

@ -1,4 +1,4 @@
#### <a href="#markupContent" name="markupContent" class="anchor"> MarkupContent </a>
#### <a href="#markupContent" name="markupContent" class="anchor">MarkupContent</a>
A `MarkupContent` literal represents a string value whose 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](https://github.github.com/gfm/).
@ -103,4 +103,3 @@ Parser | Version | Documentation
--------------- | ------- | -------------
marked | 1.1.0 | [Marked Documentation](https://marked.js.org/)
Python-Markdown | 3.2.2 | [Python-Markdown Documentation](https://python-markdown.github.io)

4
_specifications/lsp/3.18/types/partialResultParams.md
View file

@ -1,4 +1,4 @@
#### <a href="#partialResultParams" name="partialResultParams" class="anchor"> PartialResultParams </a>
#### <a href="#partialResultParams" name="partialResultParams" class="anchor">PartialResultParams</a>
A parameter literal used to pass a partial result token.
@ -10,4 +10,4 @@ export interface PartialResultParams {
*/
partialResultToken?: ProgressToken;
}
```
```

2
_specifications/lsp/3.18/types/partialResults.md
View file

@ -1,4 +1,4 @@
#### <a href="#partialResults" name="partialResults" class="anchor"> Partial Result Progress </a>
#### <a href="#partialResults" name="partialResults" class="anchor">Partial Result Progress</a>
> *Since version 3.15.0*

4
_specifications/lsp/3.18/types/patterns.md
View file

@ -1,4 +1,4 @@
#### <a href="#patterns" name="patterns" class="anchor"> Patterns </a>
#### <a href="#patterns" name="patterns" class="anchor">Patterns</a>
Pattern definitions used in file watchers and document filters.
@ -57,4 +57,4 @@ export interface RelativePattern {
* @since 3.17.0
*/
export type GlobPattern = Pattern | RelativePattern;
```
```

2
_specifications/lsp/3.18/types/position.md
View file

@ -1,4 +1,4 @@
#### <a href="#position" name="position" class="anchor"> Position </a>
#### <a href="#position" name="position" class="anchor">Position</a>
Position in a text document expressed as zero-based line and zero-based character offset. A position is between two characters like an 'insert' cursor in an editor. Special values, like `-1` to denote the end of a line, are not supported.

2
_specifications/lsp/3.18/types/range.md
View file

@ -1,4 +1,4 @@
#### <a href="#range" name="range" class="anchor"> Range </a>
#### <a href="#range" name="range" class="anchor">Range</a>
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. If you want to specify a range that contains a line including the line ending character(s) then use an end position denoting the start of the next line. For example:
```typescript

2
_specifications/lsp/3.18/types/regexp.md
View file

@ -1,4 +1,4 @@
#### <a href="#regExp" name="regExp" class="anchor"> Regular Expressions </a>
#### <a href="#regExp" name="regExp" class="anchor">Regular Expressions</a>
Regular expression are a powerful tool and there are actual use cases for them in the language server protocol. However, the downside with them is that almost every programming language has its own set of regular expression features, so the specification cannot simply refer to them as a regular expression. For this reason, the LSP uses a two step approach to support regular expressions:

2
_specifications/lsp/3.18/types/resourceChanges.md
View file

@ -1,4 +1,4 @@
### <a href="#resourceChanges" name="resourceChanges" class="anchor"> File Resource changes </a>
### <a href="#resourceChanges" name="resourceChanges" class="anchor">File Resource changes</a>
> New in version 3.13. Since version 3.16 file resource changes can carry an additional property `changeAnnotation` to describe the actual change in more detail. Whether a client has support for change annotations is guarded by the client capability `workspace.workspaceEdit.changeAnnotationSupport`.

6
_specifications/lsp/3.18/types/stringValue.md
View file

@ -1,4 +1,4 @@
#### <a href="#stringValue" name="stringValue" class="anchor"> String Value </a>
#### <a href="#stringValue" name="stringValue" class="anchor">String Value</a>
Template strings for inserting text and controlling the editor cursor upon insertion.
@ -11,7 +11,7 @@ Template strings for inserting text and controlling the editor cursor upon inser
* and `${3:foo}`. `$0` defines the final tab stop, it defaults to
* the end of the snippet. Variables are defined with `$name` and
* `${name:default value}`.
*
*
* @since 3.18.0
*/
export interface StringValue {
@ -25,4 +25,4 @@ export interface StringValue {
*/
value: string;
}
```
```

4
_specifications/lsp/3.18/types/textDocumentEdit.md
View file

@ -1,4 +1,4 @@
#### <a href="#textDocumentEdit" name="textDocumentEdit" class="anchor"> TextDocumentEdit </a>
#### <a href="#textDocumentEdit" name="textDocumentEdit" class="anchor">TextDocumentEdit</a>
* New in version 3.16: support for `AnnotatedTextEdit`. The support is guarded by the client capability `workspace.workspaceEdit.changeAnnotationSupport`. If a client doesn't signal the capability, servers shouldn't send `AnnotatedTextEdit` literals back to the client.
@ -18,7 +18,7 @@ export interface TextDocumentEdit {
*
* @since 3.16.0 - support for AnnotatedTextEdit. This is guarded by the
* client capability `workspace.workspaceEdit.changeAnnotationSupport`
*
*
* @since 3.18.0 - support for SnippetTextEdit. This is guarded by the
* client capability `workspace.workspaceEdit.snippetEditSupport`
*/

4
_specifications/lsp/3.18/types/textDocumentIdentifier.md
View file

@ -1,4 +1,4 @@
#### <a href="#textDocumentIdentifier" name="textDocumentIdentifier" class="anchor"> TextDocumentIdentifier </a>
#### <a href="#textDocumentIdentifier" name="textDocumentIdentifier" class="anchor">TextDocumentIdentifier</a>
Text documents are identified using a URI. On the protocol level, URIs are passed as strings. The corresponding JSON structure looks like this:
```typescript
@ -8,4 +8,4 @@ interface TextDocumentIdentifier {
*/
uri: DocumentUri;
}
```
```

3
_specifications/lsp/3.18/types/textDocumentItem.md
View file

@ -1,4 +1,4 @@
#### <a href="#textDocumentItem" name="textDocumentItem" class="anchor"> TextDocumentItem </a>
#### <a href="#textDocumentItem" name="textDocumentItem" class="anchor">TextDocumentItem</a>
An item to transfer a text document from the client to the server.
@ -89,4 +89,3 @@ XML | `xml`
XSL | `xsl`
YAML | `yaml`
{: .table .table-bordered .table-responsive}

2
_specifications/lsp/3.18/types/textDocumentPositionParams.md
View file

@ -1,4 +1,4 @@
#### <a href="#textDocumentPositionParams" name="textDocumentPositionParams" class="anchor"> TextDocumentPositionParams </a>
#### <a href="#textDocumentPositionParams" name="textDocumentPositionParams" class="anchor">TextDocumentPositionParams</a>
Was `TextDocumentPosition` in 1.0 with inlined parameters.

2
_specifications/lsp/3.18/types/textDocuments.md
View file

@ -1,4 +1,4 @@
#### <a href="#textDocuments" name="textDocuments" class="anchor"> Text Documents </a>
#### <a href="#textDocuments" name="textDocuments" class="anchor">Text Documents</a>
The current protocol is tailored for textual documents whose content can be represented as a string. There is currently no support for binary documents. A position inside a document (see Position definition below) is expressed as a zero-based line and character offset.

4
_specifications/lsp/3.18/types/textEdit.md
View file

@ -1,4 +1,4 @@
#### <a href="#textEdit" name="textEdit" class="anchor"> TextEdit, AnnotatedTextEdit & SnippetTextEdit </a>
#### <a href="#textEdit" name="textEdit" class="anchor">TextEdit, AnnotatedTextEdit & SnippetTextEdit</a>
- New in version 3.16: Support for `AnnotatedTextEdit`.
- New in version 3.18: Support for `SnippetTextEdit`.
@ -113,4 +113,4 @@ export interface SnippetTextEdit {
*/
annotationId?: ChangeAnnotationIdentifier;
}
```
```

2
_specifications/lsp/3.18/types/textEditArray.md
View file

@ -1,4 +1,4 @@
#### <a href="#textEditArray" name="textEditArray" class="anchor"> TextEdit[] </a>
#### <a href="#textEditArray" name="textEditArray" class="anchor">TextEdit[]</a>
Complex text manipulations are described with an array of `TextEdit`'s or `AnnotatedTextEdit`'s, representing a single change to the document.

4
_specifications/lsp/3.18/types/versionedTextDocumentIdentifier.md
View file

@ -1,4 +1,4 @@
#### <a href="#versionedTextDocumentIdentifier" name="versionedTextDocumentIdentifier" class="anchor"> VersionedTextDocumentIdentifier </a>
#### <a href="#versionedTextDocumentIdentifier" name="versionedTextDocumentIdentifier" class="anchor">VersionedTextDocumentIdentifier</a>
An identifier to denote a specific version of a text document. This information usually flows from the client to the server.
@ -33,4 +33,4 @@ interface OptionalVersionedTextDocumentIdentifier extends TextDocumentIdentifier
*/
version: integer | null;
}
```
```

14
_specifications/lsp/3.18/types/workDoneProgress.md
View file

@ -1,10 +1,10 @@
#### <a href="#workDoneProgress" name="workDoneProgress" class="anchor"> Work Done Progress </a>
#### <a href="#workDoneProgress" name="workDoneProgress" class="anchor">Work Done Progress</a>
> *Since version 3.15.0*
Work done progress is reported using the generic [`$/progress`](#progress) notification. The value payload of a work done progress notification can be of three different forms.
##### <a href="#workDoneProgressBegin" name="workDoneProgressBegin" class="anchor"> Work Done Progress Begin </a>
##### <a href="#workDoneProgressBegin" name="workDoneProgressBegin" class="anchor">Work Done Progress Begin</a>
To start progress reporting a `$/progress` notification with the following payload must be sent:
@ -49,7 +49,7 @@ export interface WorkDoneProgressBegin {
}
```
##### <a href="#workDoneProgressReport" name="workDoneProgressReport" class="anchor"> Work Done Progress Report </a>
##### <a href="#workDoneProgressReport" name="workDoneProgressReport" class="anchor">Work Done Progress Report</a>
Reporting progress is done using the following payload:
@ -88,7 +88,7 @@ export interface WorkDoneProgressReport {
}
```
##### <a href="#workDoneProgressEnd" name="workDoneProgressEnd" class="anchor"> Work Done Progress End </a>
##### <a href="#workDoneProgressEnd" name="workDoneProgressEnd" class="anchor">Work Done Progress End</a>
Signaling the end of a progress reporting is done using the following payload:
@ -105,14 +105,14 @@ export interface WorkDoneProgressEnd {
}
```
##### <a href="#initiatingWorkDoneProgress" name="initiatingWorkDoneProgress" class="anchor"> Initiating Work Done Progress </a>
##### <a href="#initiatingWorkDoneProgress" name="initiatingWorkDoneProgress" class="anchor">Initiating Work Done Progress</a>
Work Done progress can be initiated in two different ways:
1. by the sender of a request (mostly clients) using the predefined `workDoneToken` property in the requests parameter literal. The specification will refer to this kind of progress as client initiated progress.
1. by a server using the request `window/workDoneProgress/create`. The specification will refer to this kind of progress as server initiated progress.
###### <a href="#clientInitiatedProgress" name="clientInitiatedProgress" class="anchor">Client Initiated Progress </a>
###### <a href="#clientInitiatedProgress" name="clientInitiatedProgress" class="anchor">Client Initiated Progress</a>
Consider a client sending a `textDocument/reference` request to a server and the client accepts work done progress reporting on that request. To signal this to the server, the client would add a `workDoneToken` property to the reference request parameters. This might look like this:
@ -186,7 +186,7 @@ export interface WorkDoneProgressOptions {
workDoneProgress?: boolean;
}
```
###### <a href="#serverInitiatedProgress" name="serverInitiatedProgress" class="anchor">Server Initiated Progress </a>
###### <a href="#serverInitiatedProgress" name="serverInitiatedProgress" class="anchor">Server Initiated Progress</a>
Servers can also initiate progress reporting using the `window/workDoneProgress/create` request. This is useful if the server needs to report progress outside of a request (for example, if the server needs to re-index a database). The token can then be used to report progress using the same notifications used as for client initiated progress. The token provided in the create request should only be used once (e.g. only one begin, many report and one end notification should be sent to it).

4
_specifications/lsp/3.18/types/workspaceEdit.md
View file

@ -1,4 +1,4 @@
#### <a href="#workspaceEdit" name="workspaceEdit" class="anchor"> WorkspaceEdit </a>
#### <a href="#workspaceEdit" name="workspaceEdit" class="anchor">WorkspaceEdit</a>
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`.
@ -47,7 +47,7 @@ export interface WorkspaceEdit {
}
```
##### <a href="#workspaceEditClientCapabilities" name="workspaceEditClientCapabilities" class="anchor"> WorkspaceEditClientCapabilities </a>
##### <a href="#workspaceEditClientCapabilities" name="workspaceEditClientCapabilities" class="anchor">WorkspaceEditClientCapabilities</a>
> New in version 3.13: `ResourceOperationKind` and `FailureHandlingKind` and the client capability `workspace.workspaceEdit.resourceOperations` as well as `workspace.workspaceEdit.failureHandling`.

2
_specifications/lsp/3.18/window/workDoneProgressCancel.md
View file

@ -1,4 +1,4 @@
#### <a href="#window_workDoneProgress_cancel" name="window_workDoneProgress_cancel" class="anchor"> Cancel a Work Done Progress (:arrow_right:)</a>
#### <a href="#window_workDoneProgress_cancel" name="window_workDoneProgress_cancel" class="anchor">Cancel a Work Done Progress (:arrow_right:)</a>
The `window/workDoneProgress/cancel` notification is sent from the client to the server to cancel a progress initiated on the server side using `window/workDoneProgress/create`. The progress need not be marked as `cancellable` to be cancelled and a client may cancel a progress for any number of reasons: in case of error, reloading a workspace etc.

2
_specifications/lsp/3.18/window/workDoneProgressCreate.md
View file

@ -1,4 +1,4 @@
#### <a href="#window_workDoneProgress_create" name="window_workDoneProgress_create" class="anchor"> Create Work Done Progress (:arrow_right_hook:)</a>
#### <a href="#window_workDoneProgress_create" name="window_workDoneProgress_create" class="anchor">Create Work Done Progress (:arrow_right_hook:)</a>
The `window/workDoneProgress/create` request is sent from the server to the client to ask the client to create a work done progress.

2
_specifications/lsp/3.18/workspace/textDocumentContent.md
View file

@ -128,4 +128,4 @@ export interface TextDocumentContentRefreshParams {
_Response_:
* result: `void`
* error: code and message set in case an exception happens during the workspace symbol resolve request.
* error: code and message set in case an exception happens during the workspace symbol resolve request.

2
_specifications/specification-3-14.md
View file

@ -176,7 +176,7 @@ interface NotificationMessage extends Message {
Notification and requests whose methods start with '$/' are messages which are protocol implementation dependent and might not be implementable in all clients or servers. For example if the server implementation uses a single threaded synchronous programming language then there is little a server can do to react to a '$/cancelRequest' notification. If a server or client receives notifications starting with '$/' it is free to ignore the notification. If a server or client receives a requests starting with '$/' it must error the request with error code `MethodNotFound` (e.g. `-32601`).
#### <a href="#cancelRequest" name="cancelRequest" class="anchor"> Cancellation Support (:arrow_right: :arrow_left:)</a>
#### <a href="#cancelRequest" name="cancelRequest" class="anchor">Cancellation Support (:arrow_right: :arrow_left:)</a>
The base protocol offers support for request cancellation. To cancel a request, a notification message with the following properties is sent:

86
_specifications/specification-3-15.md
View file

@ -12,19 +12,19 @@ This document describes the 3.15.x version of the language server protocol. An i
**Note:** edits to this specification can be made via a pull request against this Markdown [document](https://github.com/Microsoft/language-server-protocol/blob/gh-pages/_specifications/specification-3-15.md).
## <a href="#whatIsNew" name="whatIsNew" class="anchor"> What's new in 3.15 </a>
## <a href="#whatIsNew" name="whatIsNew" class="anchor">What's new in 3.15</a>
All new 3.15 features are tagged with a corresponding since version 3.15 text or in JSDoc using `@since 3.15.0` annotation. Major new features are:
- [general progress support](#progress), [work done progress](#workDoneProgress) and [partial result progress](#partialResults)
- support for [selection ranges](#textDocument_selectionRange)
## <a href="#baseProtocol" name="baseProtocol" class="anchor"> Base Protocol </a>
## <a href="#baseProtocol" name="baseProtocol" class="anchor">Base Protocol</a>
The base protocol consists of a header and a content part (comparable to HTTP). The header and content part are
separated by a '\r\n'.
### <a href="#headerPart" name="headerPart" class="anchor"> Header Part </a>
### <a href="#headerPart" name="headerPart" class="anchor">Header Part</a>
The header part consists of header fields. Each header field is comprised of a name and a value, separated by ': ' (a colon and a space). The structure of header fields conform to the [HTTP semantic](https://tools.ietf.org/html/rfc7230#section-3.2). Each header field is terminated by '\r\n'. Considering the last header field and the overall header itself are each terminated with '\r\n', and that at least one header is mandatory, this means that two '\r\n' sequences always immediately precede the content part of a message.
@ -38,7 +38,7 @@ Currently the following header fields are supported:
The header part is encoded using the 'ascii' encoding. This includes the '\r\n' separating the header and content part.
### <a href="#contentPart" name="contentPart" class="anchor"> Content Part </a>
### <a href="#contentPart" name="contentPart" class="anchor">Content Part</a>
Contains the actual content of the message. The content part of a message uses [JSON-RPC](http://www.jsonrpc.org/) to describe requests, responses and notifications. The content part is encoded using the charset provided in the Content-Type field. It defaults to `utf-8`, which is the only encoding supported right now. If a server or client receives a header with a different encoding than `utf-8` it should respond with an error.
@ -71,7 +71,7 @@ interface Message {
jsonrpc: string;
}
```
#### <a href="#requestMessage" name="requestMessage" class="anchor"> Request Message </a>
#### <a href="#requestMessage" name="requestMessage" class="anchor">Request Message</a>
A request message to describe a request between the client and the server. Every processed request must send a response back to the sender of the request.
@ -95,7 +95,7 @@ interface RequestMessage extends Message {
}
```
#### <a href="#responseMessage" name="responseMessage" class="anchor"> Response Message </a>
#### <a href="#responseMessage" name="responseMessage" class="anchor">Response Message</a>
A Response Message sent as a result of a request. If a request doesn't provide a result value the receiver of a request still needs to return a response message to conform to the JSON RPC specification. The result property of the ResponseMessage should be set to `null` in this case to signal a successful request.
@ -153,7 +153,7 @@ export namespace ErrorCodes {
export const ContentModified: number = -32801;
}
```
#### <a href="#notificationMessage" name="notificationMessage" class="anchor"> Notification Message </a>
#### <a href="#notificationMessage" name="notificationMessage" class="anchor">Notification Message</a>
A notification message. A processed notification message must not send a response back. They work like events.
@ -171,11 +171,11 @@ interface NotificationMessage extends Message {
}
```
#### <a href="#dollarRequests" name="dollarRequests" class="anchor"> $ Notifications and Requests </a>
#### <a href="#dollarRequests" name="dollarRequests" class="anchor">$ Notifications and Requests</a>
Notification and requests whose methods start with '$/' are messages which are protocol implementation dependent and might not be implementable in all clients or servers. For example if the server implementation uses a single threaded synchronous programming language then there is little a server can do to react to a '$/cancelRequest' notification. If a server or client receives notifications starting with '$/' it is free to ignore the notification. If a server or client receives a requests starting with '$/' it must error the request with error code `MethodNotFound` (e.g. `-32601`).
#### <a href="#cancelRequest" name="cancelRequest" class="anchor"> Cancellation Support (:arrow_right: :arrow_left:)</a>
#### <a href="#cancelRequest" name="cancelRequest" class="anchor">Cancellation Support (:arrow_right: :arrow_left:)</a>
The base protocol offers support for request cancellation. To cancel a request, a notification message with the following properties is sent:
@ -194,7 +194,7 @@ interface CancelParams {
A request that got canceled still needs to return from the server and send a response back. It can not be left open / hanging. This is in line with the JSON RPC protocol that requires that every request sends a response back. In addition it allows for returning partial results on cancel. If the request returns an error response on cancellation it is advised to set the error code to `ErrorCodes.RequestCancelled`.
#### <a href="#progress" name="progress" class="anchor"> Progress Support (:arrow_right: :arrow_left:)</a>
#### <a href="#progress" name="progress" class="anchor">Progress Support (:arrow_right: :arrow_left:)</a>
> *Since version 3.15.0*
@ -233,7 +233,7 @@ The protocol currently assumes that one server serves one tool. There is current
### Basic JSON Structures
#### <a href="#uri" name="uri" class="anchor"> URI </a>
#### <a href="#uri" name="uri" class="anchor">URI</a>
URI's are transferred as strings. The URI's format is defined in [http://tools.ietf.org/html/rfc3986](http://tools.ietf.org/html/rfc3986)
@ -255,7 +255,7 @@ Many of the interfaces contain fields that correspond to the URI of a document.
type DocumentUri = string;
```
#### <a href="#textDocuments" name="textDocuments" class="anchor"> Text Documents </a>
#### <a href="#textDocuments" name="textDocuments" class="anchor">Text Documents</a>
The current protocol is tailored for textual documents whose content can be represented as a string. There is currently no support for binary documents. A position inside a document (see Position definition below) is expressed as a zero-based line and character offset. The offsets are based on a UTF-16 string representation. So in a string of the form `a𐐀b` the character offset of the character `a` is 0, the character offset of `𐐀` is 1 and the character offset of b is 3 since `𐐀` is represented using two code units in UTF-16. To ensure that both client and server split the string into the same line representation the protocol specifies the following end-of-line sequences: '\n', '\r\n' and '\r'.
@ -265,7 +265,7 @@ Positions are line end character agnostic. So you can not specify a position tha
export const EOL: string[] = ['\n', '\r\n', '\r'];
```
#### <a href="#position" name="position" class="anchor"> Position </a>
#### <a href="#position" name="position" class="anchor">Position</a>
Position in a text document expressed as zero-based line and zero-based character offset. A position is between two characters like an 'insert' cursor in an editor. Special values like for example `-1` to denote the end of a line are not supported.
@ -287,7 +287,7 @@ interface Position {
character: number;
}
```
#### <a href="#range" name="range" class="anchor"> Range </a>
#### <a href="#range" name="range" class="anchor">Range</a>
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. If you want to specify a range that contains a line including the line ending character(s) then use an end position denoting the start of the next line. For example:
```typescript
@ -311,7 +311,7 @@ interface Range {
}
```
#### <a href="#location" name="location" class="anchor"> Location </a>
#### <a href="#location" name="location" class="anchor">Location</a>
Represents a location inside a resource, such as a line inside a text file.
```typescript
@ -321,7 +321,7 @@ interface Location {
}
```
#### <a href="#locationLink" name="locationLink" class="anchor"> LocationLink </a>
#### <a href="#locationLink" name="locationLink" class="anchor">LocationLink</a>
Represents a link between a source and a target location.
@ -360,7 +360,7 @@ interface LocationLink {
}
```
#### <a href="#diagnostic" name="diagnostic" class="anchor"> Diagnostic </a>
#### <a href="#diagnostic" name="diagnostic" class="anchor">Diagnostic</a>
Represents a diagnostic, such as a compiler error or warning. Diagnostic objects are only valid in the scope of a resource.
@ -477,7 +477,7 @@ export interface DiagnosticRelatedInformation {
}
```
#### <a href="#command" name="command" class="anchor"> Command </a>
#### <a href="#command" name="command" class="anchor">Command</a>
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.
@ -499,7 +499,7 @@ interface Command {
}
```
#### <a href="#textEdit" name="textEdit" class="anchor"> TextEdit </a>
#### <a href="#textEdit" name="textEdit" class="anchor">TextEdit</a>
A textual edit applicable to a text document.
@ -519,13 +519,13 @@ interface TextEdit {
}
```
#### <a href="#textEditArray" name="textEditArray" class="anchor"> TextEdit[] </a>
#### <a href="#textEditArray" name="textEditArray" class="anchor">TextEdit[]</a>
Complex text manipulations are described with an array of `TextEdit`'s, representing a single change to the document.
All text edits ranges refer to positions in the document they are computed on. They therefore move a document from state S1 to S2 without describing any intermediate state. Text edits ranges must never overlap, that means no part of the original document must be manipulated by more than one edit. However, it is possible that multiple edits have the same start position: multiple inserts, or any number of inserts followed by a single remove or replace edit. If multiple inserts have the same position, the order in the array defines the order in which the inserted strings appear in the resulting text.
#### <a href="#textDocumentEdit" name="textDocumentEdit" class="anchor"> TextDocumentEdit </a>
#### <a href="#textDocumentEdit" name="textDocumentEdit" class="anchor">TextDocumentEdit</a>
Describes textual changes on a single text document. The text document is referred to as a `VersionedTextDocumentIdentifier` 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 of edits or do any kind of ordering. However the edits must be non overlapping.
@ -543,7 +543,7 @@ export interface TextDocumentEdit {
}
```
### <a href="#resourceChanges" name="resourceChanges" class="anchor"> File Resource changes </a>
### <a href="#resourceChanges" name="resourceChanges" class="anchor">File Resource changes</a>
> New in version 3.13:
@ -651,7 +651,7 @@ export interface DeleteFile {
}
```
#### <a href="#workspaceEdit" name="workspaceEdit" class="anchor"> WorkspaceEdit </a>
#### <a href="#workspaceEdit" name="workspaceEdit" class="anchor">WorkspaceEdit</a>
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`.
@ -684,7 +684,7 @@ export interface WorkspaceEdit {
}
```
##### <a href="#workspaceEditClientCapabilities" name="workspaceEditClientCapabilities" class="anchor"> WorkspaceEditClientCapabilities </a>
##### <a href="#workspaceEditClientCapabilities" name="workspaceEditClientCapabilities" class="anchor">WorkspaceEditClientCapabilities</a>
> New in version 3.13: `ResourceOperationKind` and `FailureHandlingKind` and the client capability `workspace.workspaceEdit.resourceOperations` as well as `workspace.workspaceEdit.failureHandling`.
@ -777,7 +777,7 @@ export namespace FailureHandlingKind {
}
```
#### <a href="#textDocumentIdentifier" name="textDocumentIdentifier" class="anchor"> TextDocumentIdentifier </a>
#### <a href="#textDocumentIdentifier" name="textDocumentIdentifier" class="anchor">TextDocumentIdentifier</a>
Text documents are identified using a URI. On the protocol level, URIs are passed as strings. The corresponding JSON structure looks like this:
```typescript
@ -789,7 +789,7 @@ interface TextDocumentIdentifier {
}
```
#### <a href="#textDocumentItem" name="textDocumentItem" class="anchor"> TextDocumentItem </a>
#### <a href="#textDocumentItem" name="textDocumentItem" class="anchor">TextDocumentItem</a>
An item to transfer a text document from the client to the server.
@ -879,7 +879,7 @@ XSL | `xsl`
YAML | `yaml`
{: .table .table-bordered .table-responsive}
#### <a href="#versionedTextDocumentIdentifier" name="versionedTextDocumentIdentifier" class="anchor"> VersionedTextDocumentIdentifier </a>
#### <a href="#versionedTextDocumentIdentifier" name="versionedTextDocumentIdentifier" class="anchor">VersionedTextDocumentIdentifier</a>
An identifier to denote a specific version of a text document.
@ -900,7 +900,7 @@ interface VersionedTextDocumentIdentifier extends TextDocumentIdentifier {
}
```
#### <a href="#textDocumentPositionParams" name="textDocumentPositionParams" class="anchor"> TextDocumentPositionParams </a>
#### <a href="#textDocumentPositionParams" name="textDocumentPositionParams" class="anchor">TextDocumentPositionParams</a>
Was `TextDocumentPosition` in 1.0 with inlined parameters.
@ -920,7 +920,7 @@ interface TextDocumentPositionParams {
}
```
#### <a href="#documentFilter" name="documentFilter" class="anchor"> DocumentFilter </a>
#### <a href="#documentFilter" name="documentFilter" class="anchor">DocumentFilter</a>
A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter that applies to JSON files with name `package.json`:
```typescript
@ -965,7 +965,7 @@ A document selector is the combination of one or more document filters.
export type DocumentSelector = DocumentFilter[];
```
#### <a href="#staticRegistrationOptions" name="staticRegistrationOptions" class="anchor"> StaticRegistrationOptions </a>
#### <a href="#staticRegistrationOptions" name="staticRegistrationOptions" class="anchor">StaticRegistrationOptions</a>
Static registration options can be used to register a feature in the initialize result with a given server control ID to be able to un-register the feature later on.
@ -982,7 +982,7 @@ export interface StaticRegistrationOptions {
}
```
#### <a href="#textDocumentRegistrationOptions" name="textDocumentRegistrationOptions" class="anchor"> TextDocumentRegistrationOptions </a>
#### <a href="#textDocumentRegistrationOptions" name="textDocumentRegistrationOptions" class="anchor">TextDocumentRegistrationOptions</a>
Options to dynamically register for requests for a set of text documents.
@ -1000,7 +1000,7 @@ export interface TextDocumentRegistrationOptions {
}
```
#### <a href="#markupContent" name="markupContent" class="anchor"> MarkupContent </a>
#### <a href="#markupContent" name="markupContent" class="anchor">MarkupContent</a>
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 can contain fenced code blocks like in [GitHub issues](https://help.github.com/articles/creating-and-highlighting-code-blocks/#syntax-highlighting)
@ -1064,13 +1064,13 @@ export interface MarkupContent {
}
```
#### <a href="#workDoneProgress" name="workDoneProgress" class="anchor"> Work Done Progress </a>
#### <a href="#workDoneProgress" name="workDoneProgress" class="anchor">Work Done Progress</a>
> *Since version 3.15.0*
Work done progress is reported using the generic [`$/progress`](#progress) notification. The value payload of a work done progress notification can be of three different forms.
##### <a href="#workDoneProgressBegin" name="workDoneProgressBegin" class="anchor"> Work Done Progress Begin </a>
##### <a href="#workDoneProgressBegin" name="workDoneProgressBegin" class="anchor">Work Done Progress Begin</a>
To start progress reporting a `$/progress` notification with the following payload must be sent:
@ -1115,7 +1115,7 @@ export interface WorkDoneProgressBegin {
}
```
##### <a href="#workDoneProgressReport" name="workDoneProgressReport" class="anchor"> Work Done Progress Report </a>
##### <a href="#workDoneProgressReport" name="workDoneProgressReport" class="anchor">Work Done Progress Report</a>
Reporting progress is done using the following payload:
@ -1155,7 +1155,7 @@ export interface WorkDoneProgressReport {
}
```
##### <a href="#workDoneProgressEnd" name="workDoneProgressEnd" class="anchor"> Work Done Progress End </a>
##### <a href="#workDoneProgressEnd" name="workDoneProgressEnd" class="anchor">Work Done Progress End</a>
Signaling the end of a progress reporting is done using the following payload:
@ -1172,14 +1172,14 @@ export interface WorkDoneProgressEnd {
}
```
##### <a href="#initiatingWorkDoneProgress" name="initiatingWorkDoneProgress" class="anchor"> Initiating Work Done Progress </a>
##### <a href="#initiatingWorkDoneProgress" name="initiatingWorkDoneProgress" class="anchor">Initiating Work Done Progress</a>
Work Done progress can be initiated in two different ways:
1. by the sender of a request (mostly clients) using the predefined `workDoneToken` property in the requests parameter literal. The document will refer to this kind of progress as client initiated progress.
1. by a server using the request `window/workDoneProgress/create`. The document will refer to this kind of progress as server initiated progress.
###### <a href="#clientInitiatedProgress" name="clientInitiatedProgress" class="anchor">Client Initiated Progress </a>
###### <a href="#clientInitiatedProgress" name="clientInitiatedProgress" class="anchor">Client Initiated Progress</a>
Consider a client sending a `textDocument/reference` request to a server and the client accepts work done progress reporting on that request. To signal this to the server the client would add a `workDoneToken` property to the reference request parameters. Something like this:
@ -1245,7 +1245,7 @@ export interface WorkDoneProgressOptions {
workDoneProgress?: boolean;
}
```
###### <a href="#serverInitiatedProgress" name="serverInitiatedProgress" class="anchor">Server Initiated Progress </a>
###### <a href="#serverInitiatedProgress" name="serverInitiatedProgress" class="anchor">Server Initiated Progress</a>
Servers can also initiate progress reporting using the `window/workDoneProgress/create` request. This is useful if the server needs to report progress outside of a request (for example the server needs to re-index a database). The returned token can then be used to report progress using the same notifications used as for client initiated progress.
@ -1264,7 +1264,7 @@ To keep the protocol backwards compatible servers are only allowed to use `windo
}
```
#### <a href="#partialResults" name="partialResults" class="anchor"> Partial Result Progress </a>
#### <a href="#partialResults" name="partialResults" class="anchor">Partial Result Progress</a>
> *Since version 3.15.0*
@ -1298,7 +1298,7 @@ If the response errors the provided partial results should be treated as follows
- the `code` equals to `RequestCancelled`: the client is free to use the provided results but should make clear that the request got canceled and may be incomplete.
- in all other cases the provided partial results shouldn't be used.
#### <a href="#partialResultParams" name="partialResultParams" class="anchor"> PartialResultParams </a>
#### <a href="#partialResultParams" name="partialResultParams" class="anchor">PartialResultParams</a>
A parameter literal used to pass a partial result token.
@ -2001,7 +2001,7 @@ interface LogMessageParams {
}
```
#### <a href="#window_workDoneProgress_create" name="window_workDoneProgress_create" class="anchor"> Creating Work Done Progress (:arrow_right_hook:)</a>
#### <a href="#window_workDoneProgress_create" name="window_workDoneProgress_create" class="anchor">Creating Work Done Progress (:arrow_right_hook:)</a>
The `window/workDoneProgress/create` request is sent from the server to the client to ask the client to create a work done progress.
@ -2024,7 +2024,7 @@ _Response_:
* result: void
* error: code and message set in case an exception happens during the 'window/workDoneProgress/create' request. In case an error occurs a server must not send any progress notification using the token provided in the `WorkDoneProgressCreateParams`.
#### <a href="#window_workDoneProgress_cancel" name="window_workDoneProgress_cancel" class="anchor"> Canceling a Work Done Progress (:arrow_right:)</a>
#### <a href="#window_workDoneProgress_cancel" name="window_workDoneProgress_cancel" class="anchor">Canceling a Work Done Progress (:arrow_right:)</a>
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`.

94
_specifications/specification-3-16.md
View file

@ -12,7 +12,7 @@ This document describes the 3.16.x version of the language server protocol. An i
**Note:** edits to this specification can be made via a pull request against this markdown [document](https://github.com/Microsoft/language-server-protocol/blob/gh-pages/_specifications/specification-3-16.md).
## <a href="#whatIsNew" name="whatIsNew" class="anchor"> What's new in 3.16 </a>
## <a href="#whatIsNew" name="whatIsNew" class="anchor">What's new in 3.16</a>
All new 3.16 features are tagged with a corresponding since version 3.16 text or in JSDoc using `@since 3.16.0` annotation. Major new feature are:
@ -27,12 +27,12 @@ A detailed list of the changes can be found in the [change log](#version_3_16_0)
The version of the specification is used to group features into a new specification release and to refer to their first appearance. Features in the spec are kept compatible using so called capability flags which are exchanged between the client and the server during initialization.
## <a href="#baseProtocol" name="baseProtocol" class="anchor"> Base Protocol </a>
## <a href="#baseProtocol" name="baseProtocol" class="anchor">Base Protocol</a>
The base protocol consists of a header and a content part (comparable to HTTP). The header and content part are
separated by a '\r\n'.
### <a href="#headerPart" name="headerPart" class="anchor"> Header Part </a>
### <a href="#headerPart" name="headerPart" class="anchor">Header Part</a>
The header part consists of header fields. Each header field is comprised of a name and a value, separated by ': ' (a colon and a space). The structure of header fields conform to the [HTTP semantic](https://tools.ietf.org/html/rfc7230#section-3.2). Each header field is terminated by '\r\n'. Considering the last header field and the overall header itself are each terminated with '\r\n', and that at least one header is mandatory, this means that two '\r\n' sequences always immediately precede the content part of a message.
@ -46,7 +46,7 @@ Currently the following header fields are supported:
The header part is encoded using the 'ascii' encoding. This includes the '\r\n' separating the header and content part.
### <a href="#contentPart" name="contentPart" class="anchor"> Content Part </a>
### <a href="#contentPart" name="contentPart" class="anchor">Content Part</a>
Contains the actual content of the message. The content part of a message uses [JSON-RPC](http://www.jsonrpc.org/) to describe requests, responses and notifications. The content part is encoded using the charset provided in the Content-Type field. It defaults to `utf-8`, which is the only encoding supported right now. If a server or client receives a header with a different encoding than `utf-8` it should respond with an error.
@ -70,7 +70,7 @@ Content-Length: ...\r\n
The following TypeScript definitions describe the base [JSON-RPC protocol](http://www.jsonrpc.org/specification):
#### <a href="#number" name="number" class="anchor"> Numbers </a>
#### <a href="#number" name="number" class="anchor">Numbers</a>
The protocol use the following definitions for integers, unsigned integers and decimal numbers:
@ -108,7 +108,7 @@ interface Message {
jsonrpc: string;
}
```
#### <a href="#requestMessage" name="requestMessage" class="anchor"> Request Message </a>
#### <a href="#requestMessage" name="requestMessage" class="anchor">Request Message</a>
A request message to describe a request between the client and the server. Every processed request must send a response back to the sender of the request.
@ -132,7 +132,7 @@ interface RequestMessage extends Message {
}
```
#### <a href="#responseMessage" name="responseMessage" class="anchor"> Response Message </a>
#### <a href="#responseMessage" name="responseMessage" class="anchor">Response Message</a>
A Response Message sent as a result of a request. If a request doesn't provide a result value the receiver of a request still needs to return a response message to conform to the JSON RPC specification. The result property of the ResponseMessage should be set to `null` in this case to signal a successful request.
@ -231,7 +231,7 @@ export namespace ErrorCodes {
export const lspReservedErrorRangeEnd: integer = -32800;
}
```
#### <a href="#notificationMessage" name="notificationMessage" class="anchor"> Notification Message </a>
#### <a href="#notificationMessage" name="notificationMessage" class="anchor">Notification Message</a>
A notification message. A processed notification message must not send a response back. They work like events.
@ -249,11 +249,11 @@ interface NotificationMessage extends Message {
}
```
#### <a href="#dollarRequests" name="dollarRequests" class="anchor"> $ Notifications and Requests </a>
#### <a href="#dollarRequests" name="dollarRequests" class="anchor">$ Notifications and Requests</a>
Notification and requests whose methods start with '\$/' are messages which are protocol implementation dependent and might not be implementable in all clients or servers. For example if the server implementation uses a single threaded synchronous programming language then there is little a server can do to react to a `$/cancelRequest` notification. If a server or client receives notifications starting with '\$/' it is free to ignore the notification. If a server or client receives a request starting with '\$/' it must error the request with error code `MethodNotFound` (e.g. `-32601`).
#### <a href="#cancelRequest" name="cancelRequest" class="anchor"> Cancellation Support (:arrow_right: :arrow_left:)</a>
#### <a href="#cancelRequest" name="cancelRequest" class="anchor">Cancellation Support (:arrow_right: :arrow_left:)</a>
The base protocol offers support for request cancellation. To cancel a request, a notification message with the following properties is sent:
@ -272,7 +272,7 @@ interface CancelParams {
A request that got canceled still needs to return from the server and send a response back. It can not be left open / hanging. This is in line with the JSON RPC protocol that requires that every request sends a response back. In addition it allows for returning partial results on cancel. If the request returns an error response on cancellation it is advised to set the error code to `ErrorCodes.RequestCancelled`.
#### <a href="#progress" name="progress" class="anchor"> Progress Support (:arrow_right: :arrow_left:)</a>
#### <a href="#progress" name="progress" class="anchor">Progress Support (:arrow_right: :arrow_left:)</a>
> *Since version 3.15.0*
@ -312,7 +312,7 @@ The protocol currently assumes that one server serves one tool. There is current
### Basic JSON Structures
#### <a href="#uri" name="uri" class="anchor"> URI </a>
#### <a href="#uri" name="uri" class="anchor">URI</a>
URI's are transferred as strings. The URI's format is defined in [https://tools.ietf.org/html/rfc3986](https://tools.ietf.org/html/rfc3986)
@ -340,7 +340,7 @@ There is also a tagging interface for normal non document URIs. It maps to a `st
type URI = string;
```
#### <a href="#regExp" name="regExp" class="anchor"> Regular Expressions </a>
#### <a href="#regExp" name="regExp" class="anchor">Regular Expressions</a>
Regular expression are a powerful tool and there are actual use cases for them in the language server protocol. However the downside with them is that almost every programming language has its own set of regular expression features so the specification can not simply refer to them as a regular expression. So the LSP uses a two step approach to support regular expressions:
@ -388,13 +388,13 @@ The following features from the [ECMAScript 2020](https://tc39.es/ecma262/#sec-r
The only regular expression flag that a client needs to support is 'i' to specify a case insensitive search.
### <a href="#enumerations" name="enumerations" class="anchor"> Enumerations </a>
### <a href="#enumerations" name="enumerations" class="anchor">Enumerations</a>
The protocol supports two kind of enumerations: (a) integer based enumerations and (b) strings based enumerations. Integer based enumerations usually start with `1`. The ones that don't are historical and they were kept to stay backwards compatible. If appropriate the value set of an enumeration is announced by the defining side (e.g. client or server) and transmitted to the other side during the initialize handshake. An example is the `CompletionItemKind` enumeration. It is announced by the client using the `textDocument.completion.completionItemKind` client property.
To support the evolution of enumerations the using side of an enumeration shouldn't fail on an enumeration value it doesn't know. It should simply ignore it as a value it can use and try to do its best to preserve the value on round trips. Lets look at the `CompletionItemKind` enumeration as an example again: if in a future version of the specification an additional completion item kind with the value `n` gets added and announced by a client a (older) server not knowing about the value should not fail but simply ignore the value as a usable item kind.
#### <a href="#textDocuments" name="textDocuments" class="anchor"> Text Documents </a>
#### <a href="#textDocuments" name="textDocuments" class="anchor">Text Documents</a>
The current protocol is tailored for textual documents whose content can be represented as a string. There is currently no support for binary documents. A position inside a document (see Position definition below) is expressed as a zero-based line and character offset. The offsets are based on a UTF-16 string representation. So in a string of the form `a𐐀b` the character offset of the character `a` is 0, the character offset of `𐐀` is 1 and the character offset of b is 3 since `𐐀` is represented using two code units in UTF-16. To ensure that both client and server split the string into the same line representation the protocol specifies the following end-of-line sequences: '\n', '\r\n' and '\r'.
@ -404,7 +404,7 @@ Positions are line end character agnostic. So you can not specify a position tha
export const EOL: string[] = ['\n', '\r\n', '\r'];
```
#### <a href="#position" name="position" class="anchor"> Position </a>
#### <a href="#position" name="position" class="anchor">Position</a>
Position in a text document expressed as zero-based line and zero-based character offset. A position is between two characters like an 'insert' cursor in an editor. Special values like for example `-1` to denote the end of a line are not supported.
@ -426,7 +426,7 @@ interface Position {
character: uinteger;
}
```
#### <a href="#range" name="range" class="anchor"> Range </a>
#### <a href="#range" name="range" class="anchor">Range</a>
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. If you want to specify a range that contains a line including the line ending character(s) then use an end position denoting the start of the next line. For example:
```typescript
@ -450,7 +450,7 @@ interface Range {
}
```
#### <a href="#location" name="location" class="anchor"> Location </a>
#### <a href="#location" name="location" class="anchor">Location</a>
Represents a location inside a resource, such as a line inside a text file.
```typescript
@ -460,7 +460,7 @@ interface Location {
}
```
#### <a href="#locationLink" name="locationLink" class="anchor"> LocationLink </a>
#### <a href="#locationLink" name="locationLink" class="anchor">LocationLink</a>
Represents a link between a source and a target location.
@ -497,7 +497,7 @@ interface LocationLink {
}
```
#### <a href="#diagnostic" name="diagnostic" class="anchor"> Diagnostic </a>
#### <a href="#diagnostic" name="diagnostic" class="anchor">Diagnostic</a>
Represents a diagnostic, such as a compiler error or warning. Diagnostic objects are only valid in the scope of a resource.
@ -646,7 +646,7 @@ export interface CodeDescription {
}
```
#### <a href="#command" name="command" class="anchor"> Command </a>
#### <a href="#command" name="command" class="anchor">Command</a>
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.
@ -668,7 +668,7 @@ interface Command {
}
```
#### <a href="#textEdit" name="textEdit" class="anchor"> TextEdit & AnnotatedTextEdit </a>
#### <a href="#textEdit" name="textEdit" class="anchor">TextEdit & AnnotatedTextEdit</a>
> New in version 3.16: Support for `AnnotatedTextEdit`.
@ -745,13 +745,13 @@ export interface AnnotatedTextEdit extends TextEdit {
}
```
#### <a href="#textEditArray" name="textEditArray" class="anchor"> TextEdit[] </a>
#### <a href="#textEditArray" name="textEditArray" class="anchor">TextEdit[]</a>
Complex text manipulations are described with an array of `TextEdit`'s or `AnnotatedTextEdit`'s, representing a single change to the document.
All text edits ranges refer to positions in the document they are computed on. They therefore move a document from state S1 to S2 without describing any intermediate state. Text edits ranges must never overlap, that means no part of the original document must be manipulated by more than one edit. However, it is possible that multiple edits have the same start position: multiple inserts, or any number of inserts followed by a single remove or replace edit. If multiple inserts have the same position, the order in the array defines the order in which the inserted strings appear in the resulting text.
#### <a href="#textDocumentEdit" name="textDocumentEdit" class="anchor"> TextDocumentEdit </a>
#### <a href="#textDocumentEdit" name="textDocumentEdit" class="anchor">TextDocumentEdit</a>
> New in version 3.16: support for `AnnotatedTextEdit`. The support is guarded by the client capability `workspace.workspaceEdit.changeAnnotationSupport`. If a client doesn't signal the capability, servers shouldn't send `AnnotatedTextEdit` literals back to the client.
@ -774,7 +774,7 @@ export interface TextDocumentEdit {
}
```
### <a href="#resourceChanges" name="resourceChanges" class="anchor"> File Resource changes </a>
### <a href="#resourceChanges" name="resourceChanges" class="anchor">File Resource changes</a>
> New in version 3.13. Since version 3.16 file resource changes can carry an additional property `changeAnnotation` to describe the actual change in more detail. Whether a client has support for change annotations is guarded by the client capability `workspace.workspaceEdit.changeAnnotationSupport`.
@ -913,7 +913,7 @@ export interface DeleteFile {
}
```
#### <a href="#workspaceEdit" name="workspaceEdit" class="anchor"> WorkspaceEdit </a>
#### <a href="#workspaceEdit" name="workspaceEdit" class="anchor">WorkspaceEdit</a>
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`.
@ -963,7 +963,7 @@ export interface WorkspaceEdit {
}
```
##### <a href="#workspaceEditClientCapabilities" name="workspaceEditClientCapabilities" class="anchor"> WorkspaceEditClientCapabilities </a>
##### <a href="#workspaceEditClientCapabilities" name="workspaceEditClientCapabilities" class="anchor">WorkspaceEditClientCapabilities</a>
> New in version 3.13: `ResourceOperationKind` and `FailureHandlingKind` and the client capability `workspace.workspaceEdit.resourceOperations` as well as `workspace.workspaceEdit.failureHandling`.
@ -1080,7 +1080,7 @@ export namespace FailureHandlingKind {
}
```
#### <a href="#textDocumentIdentifier" name="textDocumentIdentifier" class="anchor"> TextDocumentIdentifier </a>
#### <a href="#textDocumentIdentifier" name="textDocumentIdentifier" class="anchor">TextDocumentIdentifier</a>
Text documents are identified using a URI. On the protocol level, URIs are passed as strings. The corresponding JSON structure looks like this:
```typescript
@ -1092,7 +1092,7 @@ interface TextDocumentIdentifier {
}
```
#### <a href="#textDocumentItem" name="textDocumentItem" class="anchor"> TextDocumentItem </a>
#### <a href="#textDocumentItem" name="textDocumentItem" class="anchor">TextDocumentItem</a>
An item to transfer a text document from the client to the server.
@ -1182,7 +1182,7 @@ XSL | `xsl`
YAML | `yaml`
{: .table .table-bordered .table-responsive}
#### <a href="#versionedTextDocumentIdentifier" name="versionedTextDocumentIdentifier" class="anchor"> VersionedTextDocumentIdentifier </a>
#### <a href="#versionedTextDocumentIdentifier" name="versionedTextDocumentIdentifier" class="anchor">VersionedTextDocumentIdentifier</a>
An identifier to denote a specific version of a text document. This information usually flows from the client to the server.
@ -1217,7 +1217,7 @@ interface OptionalVersionedTextDocumentIdentifier extends TextDocumentIdentifier
}
```
#### <a href="#textDocumentPositionParams" name="textDocumentPositionParams" class="anchor"> TextDocumentPositionParams </a>
#### <a href="#textDocumentPositionParams" name="textDocumentPositionParams" class="anchor">TextDocumentPositionParams</a>
Was `TextDocumentPosition` in 1.0 with inlined parameters.
@ -1237,7 +1237,7 @@ interface TextDocumentPositionParams {
}
```
#### <a href="#documentFilter" name="documentFilter" class="anchor"> DocumentFilter </a>
#### <a href="#documentFilter" name="documentFilter" class="anchor">DocumentFilter</a>
A document filter denotes a document through properties like `language`, `scheme` or `pattern`. An example is a filter that applies to TypeScript files on disk. Another example is a filter that applies to JSON files with name `package.json`:
```typescript
@ -1282,7 +1282,7 @@ A document selector is the combination of one or more document filters.
export type DocumentSelector = DocumentFilter[];
```
#### <a href="#staticRegistrationOptions" name="staticRegistrationOptions" class="anchor"> StaticRegistrationOptions </a>
#### <a href="#staticRegistrationOptions" name="staticRegistrationOptions" class="anchor">StaticRegistrationOptions</a>
Static registration options can be used to register a feature in the initialize result with a given server control ID to be able to un-register the feature later on.
@ -1299,7 +1299,7 @@ export interface StaticRegistrationOptions {
}
```
#### <a href="#textDocumentRegistrationOptions" name="textDocumentRegistrationOptions" class="anchor"> TextDocumentRegistrationOptions </a>
#### <a href="#textDocumentRegistrationOptions" name="textDocumentRegistrationOptions" class="anchor">TextDocumentRegistrationOptions</a>
Options to dynamically register for requests for a set of text documents.
@ -1316,7 +1316,7 @@ export interface TextDocumentRegistrationOptions {
}
```
#### <a href="#markupContent" name="markupContent" class="anchor"> MarkupContent </a>
#### <a href="#markupContent" name="markupContent" class="anchor">MarkupContent</a>
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](https://github.github.com/gfm/).
@ -1408,13 +1408,13 @@ Parser | Version | Documentation
marked | 1.1.0 | [Marked Documentation](https://marked.js.org/)
#### <a href="#workDoneProgress" name="workDoneProgress" class="anchor"> Work Done Progress </a>
#### <a href="#workDoneProgress" name="workDoneProgress" class="anchor">Work Done Progress</a>
> *Since version 3.15.0*
Work done progress is reported using the generic [`$/progress`](#progress) notification. The value payload of a work done progress notification can be of three different forms.
##### <a href="#workDoneProgressBegin" name="workDoneProgressBegin" class="anchor"> Work Done Progress Begin </a>
##### <a href="#workDoneProgressBegin" name="workDoneProgressBegin" class="anchor">Work Done Progress Begin</a>
To start progress reporting a `$/progress` notification with the following payload must be sent:
@ -1459,7 +1459,7 @@ export interface WorkDoneProgressBegin {
}
```
##### <a href="#workDoneProgressReport" name="workDoneProgressReport" class="anchor"> Work Done Progress Report </a>
##### <a href="#workDoneProgressReport" name="workDoneProgressReport" class="anchor">Work Done Progress Report</a>
Reporting progress is done using the following payload:
@ -1498,7 +1498,7 @@ export interface WorkDoneProgressReport {
}
```
##### <a href="#workDoneProgressEnd" name="workDoneProgressEnd" class="anchor"> Work Done Progress End </a>
##### <a href="#workDoneProgressEnd" name="workDoneProgressEnd" class="anchor">Work Done Progress End</a>
Signaling the end of a progress reporting is done using the following payload:
@ -1515,14 +1515,14 @@ export interface WorkDoneProgressEnd {
}
```
##### <a href="#initiatingWorkDoneProgress" name="initiatingWorkDoneProgress" class="anchor"> Initiating Work Done Progress </a>
##### <a href="#initiatingWorkDoneProgress" name="initiatingWorkDoneProgress" class="anchor">Initiating Work Done Progress</a>
Work Done progress can be initiated in two different ways:
1. by the sender of a request (mostly clients) using the predefined `workDoneToken` property in the requests parameter literal. The document will refer to this kind of progress as client initiated progress.
1. by a server using the request `window/workDoneProgress/create`. The document will refer to this kind of progress as server initiated progress.
###### <a href="#clientInitiatedProgress" name="clientInitiatedProgress" class="anchor">Client Initiated Progress </a>
###### <a href="#clientInitiatedProgress" name="clientInitiatedProgress" class="anchor">Client Initiated Progress</a>
Consider a client sending a `textDocument/reference` request to a server and the client accepts work done progress reporting on that request. To signal this to the server the client would add a `workDoneToken` property to the reference request parameters. Something like this:
@ -1590,7 +1590,7 @@ export interface WorkDoneProgressOptions {
workDoneProgress?: boolean;
}
```
###### <a href="#serverInitiatedProgress" name="serverInitiatedProgress" class="anchor">Server Initiated Progress </a>
###### <a href="#serverInitiatedProgress" name="serverInitiatedProgress" class="anchor">Server Initiated Progress</a>
Servers can also initiate progress reporting using the `window/workDoneProgress/create` request. This is useful if the server needs to report progress outside of a request (for example the server needs to re-index a database). The returned token can then be used to report progress using the same notifications used as for client initiated progress. A token obtained using the create request should only be used once (e.g. only one begin, many report and one end notification should be sent to it).
@ -1609,7 +1609,7 @@ To keep the protocol backwards compatible servers are only allowed to use `windo
};
```
#### <a href="#partialResults" name="partialResults" class="anchor"> Partial Result Progress </a>
#### <a href="#partialResults" name="partialResults" class="anchor">Partial Result Progress</a>
> *Since version 3.15.0*
@ -1643,7 +1643,7 @@ If the response errors the provided partial results should be treated as follows
- the `code` equals to `RequestCancelled`: the client is free to use the provided results but should make clear that the request got canceled and may be incomplete.
- in all other cases the provided partial results shouldn't be used.
#### <a href="#partialResultParams" name="partialResultParams" class="anchor"> PartialResultParams </a>
#### <a href="#partialResultParams" name="partialResultParams" class="anchor">PartialResultParams</a>
A parameter literal used to pass a partial result token.
@ -1657,7 +1657,7 @@ export interface PartialResultParams {
}
```
#### <a href="#traceValue" name="traceValue" class="anchor"> TraceValue </a>
#### <a href="#traceValue" name="traceValue" class="anchor">TraceValue</a>
A `TraceValue` represents the level of verbosity with which the server systematically reports its execution trace using [$/logTrace](#logTrace) notifications.
The initial trace value is set by the client at initialization and can be modified later using the [$/setTrace](#setTrace) notification.
@ -2722,7 +2722,7 @@ interface LogMessageParams {
}
```
#### <a href="#window_workDoneProgress_create" name="window_workDoneProgress_create" class="anchor"> Creating Work Done Progress (:arrow_right_hook:)</a>
#### <a href="#window_workDoneProgress_create" name="window_workDoneProgress_create" class="anchor">Creating Work Done Progress (:arrow_right_hook:)</a>
The `window/workDoneProgress/create` request is sent from the server to the client to ask the client to create a work done progress.
@ -2745,7 +2745,7 @@ _Response_:
* result: void
* error: code and message set in case an exception happens during the 'window/workDoneProgress/create' request. In case an error occurs a server must not send any progress notification using the token provided in the `WorkDoneProgressCreateParams`.
#### <a href="#window_workDoneProgress_cancel" name="window_workDoneProgress_cancel" class="anchor"> Canceling a Work Done Progress (:arrow_right:)</a>
#### <a href="#window_workDoneProgress_cancel" name="window_workDoneProgress_cancel" class="anchor">Canceling a Work Done Progress (:arrow_right:)</a>
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 progress need not be marked as `cancellable` to be cancelled and a client may cancel a progress for any number of reasons: in case of error, reloading a workspace etc.

2
resources/notes.md
View file

@ -13,4 +13,4 @@
- glossary? development tool (not client), language server, SDK
### Layout
- home page: less space below the header page
- home page: less space below the header page