### Capabilities Vertex Example

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Example of a capabilities vertex defining token types and modifiers.

```json
{
    "semanticTokensProvider": {
      "tokenTypes": [ "object" ],
      "tokenModifiers": [ "static" ]
  },
  "label": "capabilities"
}
```

--------------------------------

### Sample TypeScript File

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_overviews/lsif/overview.md

A basic TypeScript file used as an example.

```typescript
function bar(): void {
}

```

--------------------------------

### Concrete LSP Request Examples

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Provides specific examples of LSP requests for folding ranges and hover information, showing the expected input and output types.

```typescript
request(
  'file:///Users/dirkb/sample/test.ts',
  'textDocument/foldingRange'
) -> FoldingRange[];
```

```typescript
request(
  'file:///Users/dirkb/sample/test.ts',
  { line: 10, character: 17 },
  'textDocument/hover'
) -> Hover;
```

--------------------------------

### URI Structure Example

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_includes/types/uri.md

Illustrates the different components of a URI according to RFC 3986.

```plaintext
  foo://example.com:8042/over/there?name=ferret#nose
  \_/   \______________/\_________/ \_________/ \__/
   |           |            |            |        |
scheme     authority       path        query   fragment
   |   _____________________|__
  / \ /                        \
  urn:example:animal:ferret:nose
```

--------------------------------

### Progress Notification Parameters

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/types/workDoneProgress.md

Example of the $/progress notification parameters used by a server to report progress.

```json
{
	"token": "1d546990-40a3-4b77-b134-46622995f6ae",
	"value": {
		"kind": "begin",
		"title": "Finding references for A#foo",
		"cancellable": false,
		"message": "Processing file X.ts",
		"percentage": 0
	}
}
```

--------------------------------

### Specify project root for LSIF indexer

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/implementation.md

Example of using the project flag to point the indexer to a specific configuration file.

```bash
lsif-tsc --project ./frontend/tsconfig.json
```

--------------------------------

### DocumentFilter Examples

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/types/documentFilter.md

Examples of filter objects targeting specific file types and patterns.

```typescript
{ language: 'typescript', scheme: 'file' }
{ language: 'json', pattern: '**/package.json' }
```

--------------------------------

### package.json Example

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

A sample package.json file used in an LSIF context. This defines the project's name, version, and main entry point.

```json
{
  "name": "lsif-ts-sample",
  "version": "1.0.0",
  "description": "",
  "main": "lib/index.js",
  "author": "MS",
  "license": "MIT"
}
```

--------------------------------

### Example TypeScript source code

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Sample TypeScript code used to demonstrate vertex and edge emission.

```typescript
interface I {
  foo(): void;
}

let i: I;
```

--------------------------------

### Define Project P1 Source File

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Example TypeScript file for Project P1 containing a Disposable interface.

```typescript
export interface Disposable {
	dispose(): void;
}

let d: Disposable;
d.dispose();
```

--------------------------------

### npm Package Moniker Example

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

This example shows how a moniker is generated for an npm package import, specifically for 'mobx::ObservableMap' from the 'mobx' npm package.

```json
{
  id: 978,
  type: "vertex",
  label: "moniker",
  kind: "import",
  scheme: "npm",
  identifier: "mobx::ObservableMap",
  unique: 'scheme'
}
```

--------------------------------

### Example JSON-RPC Registration Message

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_includes/messages/3.17/registerCapability.md

A sample JSON-RPC message for dynamically registering the textDocument/willSaveWaitUntil capability.

```json
{
	"method": "client/registerCapability",
	"params": {
		"registrations": [
			{
				"id": "79eee87c-c409-4664-8102-e03263673f6f",
				"method": "textDocument/willSaveWaitUntil",
				"registerOptions": {
					"documentSelector": [
						{ "language": "javascript" }
					]
				}
			}
		]
	}
}
```

--------------------------------

### Server Capability for Work Done Progress

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/types/workDoneProgress.md

Example of setting server capabilities to signal support for work done progress.

```json
{
	"referencesProvider": {
		"workDoneProgress": true
	}
}
```

--------------------------------

### TypeScript Interface and Class Example

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

A TypeScript example demonstrating method overriding across multiple interfaces.

```typescript
interface I {
  foo(): void;
}

interface II {
  foo(): void;
}

class B implements I, II {
  foo(): void {
  }
}

let i: I;
i.foo();

let b: B;
b.foo();
```

--------------------------------

### Configure Inlay Hint Resolve Support

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/language/inlayHint.md

Example of announcing support for lazy resolution of label locations.

```typescript
textDocument.inlayHint.resolveSupport = { properties: ['label.location'] };
```

--------------------------------

### Client-Initiated Progress Request Parameters

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/types/workDoneProgress.md

Example of a request parameter object including a workDoneToken to signal progress reporting support.

```json
{
	"textDocument": {
		"uri": "file:///folder/file.ts"
	},
	"position": {
		"line": 9,
		"character": 5
	},
	"context": {
		"includeDeclaration": true
	},
	// The token used to report work done progress.
	"workDoneToken": "1d546990-40a3-4b77-b134-46622995f6ae"
}
```

--------------------------------

### Example TypeScript Semantic Tokens Input

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Sample TypeScript code used to demonstrate semantic token classification.

```typescript
function hello() {
  console.log('Hello');
}
```

--------------------------------

### Complex TypeScript Example for References

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

A TypeScript example demonstrating interfaces, classes implementing interfaces, and method calls. This scenario is used to illustrate how a single reference result can aggregate multiple definitions and references across different implementations and call sites.

```typescript
interface I {
  foo(): void;
}

class A implements I {
  foo(): void {
  }
}

class B implements I {
  foo(): void {
  }
}

let i: I;
i.foo();

let b: B;
b.foo();
```

--------------------------------

### Example TypeScript source for folding range

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Sample TypeScript code used to demonstrate folding range functionality.

```typescript
function hello() {
  console.log('Hello');
}

function world() {
  console.log('world');
}

function space() {
  console.log(' ');
}
hello();space();world();
```

--------------------------------

### Emit project lifecycle events

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Example of project and document lifecycle events including containment edges.

```ts
{ id: 2, type: "vertex", label: "project", kind: "typescript" }
{ id: 4, type: "vertex", label: "document",
  uri: "file:///Users/dirkb/sample.ts", languageId: "typescript",
  contents: "..."
}
{ id: 5, type: "vertex", label: "$event",
  kind: "begin", scope: "document" , data: 4
}
{ id: 3, type: "vertex", label: "$event",
  kind: "begin", scope: "project", data: 2
}
{ id: 53, type: "vertex", label: "$event",
  kind: "end", scope: "document", data: 4
}
{ id: 54, type: "edge", label: "contains", outV: 2, inVs: [4] }
{ id: 55, type: "vertex", label: "$event",
  kind: "end", scope: "project", data: 2
}
```

--------------------------------

### Emit document begin and end events

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Example of document vertex emission followed by begin and end lifecycle events.

```ts
// The actual document
{ id: 4, type: "vertex", label: "document",
  uri: "file:///Users/dirkb/sample.ts", languageId: "typescript",
  contents: "..."
}
// The begin event
{ id: 5, type: "vertex", label: "$event",
  kind: "begin", scope: "document" , data: 4
}
// The end event
{ id: 53, type: "vertex", label: "$event",
  kind: "end", scope: "document" , data: 4
}
```

--------------------------------

### Example Code Action without Edit

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/language/codeAction.md

An example of a code action that only has a title, requiring resolution to compute its edit property. This is useful for deferring expensive computations.

```json
{
    "title": "Do Foo"
}
```

--------------------------------

### Define Project P2 Source File

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Example TypeScript file for Project P2 that imports and implements the Disposable interface from P1.

```typescript
import { Disposable } from 'p1';

class Widget implements Disposable {
	public dispose(): void {
	}
}

let w: Widget;
w.dispose();
```

--------------------------------

### Snippet Variable Transform Example

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/language/completion.md

This example demonstrates how to insert the current filename without its extension using a variable transform. It resolves to the filename, captures everything before the final '.suffix', and outputs the captured group.

```plaintext
${TM_FILENAME/(.*)\..+$/$1/}
```

--------------------------------

### LSP Message Structure Example

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/specification.md

Illustrates the structure of a Language Server Protocol message, including the header and JSON-RPC content. Ensure the Content-Length header accurately reflects the byte size of the content part.

```plaintext
Content-Length: ...\r\n
\r

{
	"jsonrpc": "2.0",
	"id": 1,
	"method": "textDocument/completion",
	"params": {
		...
	}
}
```

--------------------------------

### TypeScript Import Example

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

A TypeScript code snippet demonstrating the import of an external npm package ('mobx'). This is used to illustrate how imported symbols are represented in LSIF.

```typescript
import * as mobx from 'mobx';

let map: mobx.ObservableMap = new mobx.ObservableMap();
```

--------------------------------

### Example ResultSet Graph Output

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

A sample representation of a document, range, and result set linked via edges to provide hover information.

```json
{ id: 1, type: "vertex", label: "document",
  uri: "file:///Users/dirkb/sample.ts", languageId: "typescript"
}
{ id: 2, type: "vertex", label: "resultSet" }
{ id: 3, type: "vertex", label: "range",
  start: { line: 0, character: 9}, end: { line: 0, character: 12 }
}
{ id: 4, type: "edge", label: "contains", outV: 1, inVs: [3] }
{ id: 5, type: "edge", label: "next", outV: 3, inV: 2 }
{ id: 6, type: "vertex", label: "hoverResult",
  result: {
    "contents":[ {
      language: "typescript", value:"function bar(): void"
    }]
  }
}
{ id: 7, type: "edge", label: "textDocument/hover", outV: 2, inV: 6 }
```

--------------------------------

### URI Encoding Variations

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_includes/types/uri.md

Shows two valid URI examples demonstrating potential differences in encoding, such as colons in drive letters.

```plaintext
file:///c:/project/readme.md
file:///C%3A/project/readme.md
```

--------------------------------

### Define TypeScript source for LSIF export example

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

A sample TypeScript file used to demonstrate how exported functions and classes are represented in LSIF.

```typescript
export function func(): void {
}

export class Emitter {
  private doEmit() {
  }

  public emit() {
    this.doEmit();
  }
}
```

--------------------------------

### Range Example

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/types/range.md

A range in a text document expressed as zero-based start and end positions. The end position is exclusive.

```typescript
{
    start: { line: 5, character: 23 },
    end : { line: 6, character: 0 }
}
```

--------------------------------

### Implementation Provider

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/general/initialize.md

Configuration for the go to implementation feature.

```APIDOC
## Implementation Provider

### Description
The server provides goto implementation support.

@since 3.6.0

### Parameters
#### Request Body
- **implementationProvider** (boolean | ImplementationOptions | ImplementationRegistrationOptions) - Optional - The server provides goto implementation support.
```

--------------------------------

### Concrete Hover Result Example

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_overviews/lsif/overview.md

An example of a concrete hover result value conforming to the LSP Hover interface.

```typescript
{
  contents: [
    { language: "typescript", value: "function bar(): void" }
  ]
}

```

--------------------------------

### TypeScript Hover Result Example

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Example of a hover result vertex, including its contents and the associated range, for a textDocument/hover request.

```typescript
{
  id: 6,
  type: "vertex",
  label: "hoverResult",
  result: {
    contents: [ { language: "typescript", value: "function bar(): void" } ],
    range: { line: 4, character: 2 }, end: { line: 4, character: 5 }
  }
}
```

--------------------------------

### Perform Initialize Request and Response

Source: https://context7.com/microsoft/language-server-protocol/llms.txt

The client initiates the connection by sending capabilities, and the server responds with its supported features.

```typescript
// Client sends initialize request
const initializeRequest = {
  jsonrpc: "2.0",
  id: 1,
  method: "initialize",
  params: {
    processId: 1234,
    clientInfo: {
      name: "My Editor",
      version: "1.0.0"
    },
    locale: "en-US",
    rootUri: "file:///workspace/myproject",
    capabilities: {
      textDocument: {
        synchronization: {
          dynamicRegistration: true,
          willSave: true,
          willSaveWaitUntil: true,
          didSave: true
        },
        completion: {
          dynamicRegistration: true,
          completionItem: {
            snippetSupport: true,
            commitCharactersSupport: true,
            documentationFormat: ["markdown", "plaintext"],
            deprecatedSupport: true,
            preselectSupport: true
          },
          contextSupport: true
        },
        hover: {
          dynamicRegistration: true,
          contentFormat: ["markdown", "plaintext"]
        },
        definition: {
          dynamicRegistration: true,
          linkSupport: true
        },
        references: {
          dynamicRegistration: true
        },
        documentSymbol: {
          dynamicRegistration: true,
          hierarchicalDocumentSymbolSupport: true
        },
        codeAction: {
          dynamicRegistration: true,
          codeActionLiteralSupport: {
            codeActionKind: {
              valueSet: ["quickfix", "refactor", "refactor.extract", "source.organizeImports"]
            }
          },
          isPreferredSupport: true,
          resolveSupport: { properties: ["edit"] }
        },
        rename: {
          dynamicRegistration: true,
          prepareSupport: true
        }
      },
      workspace: {
        applyEdit: true,
        workspaceEdit: {
          documentChanges: true
        },
        workspaceFolders: true,
        configuration: true
      }
    },
    workspaceFolders: [
      { uri: "file:///workspace/myproject", name: "myproject" }
    ]
  }
};

// Server responds with its capabilities
const initializeResponse = {
  jsonrpc: "2.0",
  id: 1,
  result: {
    capabilities: {
      textDocumentSync: {
        openClose: true,
        change: 2, // Incremental
        save: { includeText: true }
      },
      completionProvider: {
        triggerCharacters: [".", ":", "<"],
        resolveProvider: true
      },
      hoverProvider: true,
      definitionProvider: true,
      referencesProvider: true,
      documentSymbolProvider: true,
      workspaceSymbolProvider: true,
      codeActionProvider: {
        codeActionKinds: ["quickfix", "refactor"],
        resolveProvider: true
      },
      renameProvider: {
        prepareProvider: true
      },
      documentFormattingProvider: true
    },
    serverInfo: {
      name: "My Language Server",
      version: "1.0.0"
    }
  }
};
```

--------------------------------

### Local Variable Moniker Example (TypeScript)

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

This example demonstrates the LSIF structure for a moniker associated with a local variable 'x' in a TypeScript function. The 'kind' is 'local' and the 'scheme' is 'tsc'.

```typescript
{
  id: 13,
  type: "vertex",
  label: "resultSet"
}
{
  id: 14,
  type: "vertex",
  label: "moniker",
  kind: "local",
  scheme: "tsc",
  identifier: "SfeOP6s53Y2HAkcViolxYA==",
  unique: 'document'
}
{
  id: 15,
  type: "edge",
  label: "moniker",
  outV: 13,
  inV: 14
}
{
  id: 16,
  type: "vertex",
  label: "range",
  start: { line: 0, character: 13 },
  end: { line: 0, character: 14 },
  tag: {
    type: "definition",
    text: "x",
    kind: 7,
    fullRange: {
      start: { line: 0, character: 13 },
      end: { line: 0, character: 22 }
    }
  }
}
{
  id: 17,
  type: "edge",
  label: "next",
  outV: 16,
  inV: 13
}
```

--------------------------------

### workspace/configuration

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/workspace/configuration.md

Request sent from the server to the client to fetch configuration settings.

```APIDOC
## workspace/configuration

### Description
The `workspace/configuration` request is sent from the server to the client to fetch configuration settings. It supports fetching multiple settings in one roundtrip.

### Method
Request (Server to Client)

### Endpoint
workspace/configuration

### Parameters
#### Request Body (ConfigurationParams)
- **items** (ConfigurationItem[]) - Required - The list of configuration items to fetch.

#### ConfigurationItem
- **scopeUri** (URI) - Optional - The scope to get the configuration section for.
- **section** (string) - Optional - The configuration section asked for.

### Response
#### Success Response
- **result** (LSPAny[]) - An array of configuration settings corresponding to the order of the requested items. If a setting cannot be provided, null is returned.

#### Error Handling
- Returns standard LSP error codes and messages if an exception occurs.
```

--------------------------------

### Define a function in TypeScript

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Example function used to demonstrate position-based requests.

```typescript
function bar() {
}
```

--------------------------------

### TypeScript Function Definitions

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Example of TypeScript functions used to demonstrate the textDocument/definition request.

```typescript
function bar() {
}

function foo() {
  bar();
}
```

--------------------------------

### Document and Project Begin/End Events

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Demonstrates the use of begin and end events for documents and projects to manage the lifecycle and ordering of LSIF data.

```APIDOC
## Document and Project Begin/End Events

### Description
Begin and end events are emitted for documents and projects to facilitate processing and ensure correct data ordering within an LSIF dump. After a document's end event, no further data referencing that document should appear, except for its inclusion in a project.

### Method
N/A (Data Structure Representation)

### Endpoint
N/A (Data Structure Representation)

### Request Body
**Document Event:**
```json
{
  "id": "number",
  "type": "vertex",
  "label": "$event",
  "kind": "begin" | "end",
  "scope": "document",
  "data": "number (ID of the document vertex)"
}
```

**Project Event:**
```json
{
  "id": "number",
  "type": "vertex",
  "label": "$event",
  "kind": "begin" | "end",
  "scope": "project",
  "data": "number (ID of the project vertex)"
}
```

### Response
N/A (Data Structure Representation)

### Example (Document Events)
```json
// Document vertex
{
  "id": 4,
  "type": "vertex",
  "label": "document",
  "uri": "file:///Users/dirkb/sample.ts",
  "languageId": "typescript",
  "contents": "..."
}
// Begin event for the document
{
  "id": 5,
  "type": "vertex",
  "label": "$event",
  "kind": "begin",
  "scope": "document",
  "data": 4
}
// End event for the document
{
  "id": 53,
  "type": "vertex",
  "label": "$event",
  "kind": "end",
  "scope": "document",
  "data": 4
}
```

### Example (Project and Document Events)
```json
// Project vertex
{
  "id": 2,
  "type": "vertex",
  "label": "project",
  "kind": "typescript"
}
// Document vertex
{
  "id": 4,
  "type": "vertex",
  "label": "document",
  "uri": "file:///Users/dirkb/sample.ts",
  "languageId": "typescript",
  "contents": "..."
}
// Begin event for the document
{
  "id": 5,
  "type": "vertex",
  "label": "$event",
  "kind": "begin",
  "scope": "document",
  "data": 4
}
// Begin event for the project
{
  "id": 3,
  "type": "vertex",
  "label": "$event",
  "kind": "begin",
  "scope": "project",
  "data": 2
}
// End event for the document
{
  "id": 53,
  "type": "vertex",
  "label": "$event",
  "kind": "end",
  "scope": "document",
  "data": 4
}
// Contains edge linking document to project
{
  "id": 54,
  "type": "edge",
  "label": "contains",
  "outV": 2,
  "inVs": [
    4
  ]
}
// End event for the project
{
  "id": 55,
  "type": "vertex",
  "label": "$event",
  "kind": "end",
  "scope": "project",
  "data": 2
}
```
```

--------------------------------

### Example JSON-RPC Unregister Message

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_includes/messages/3.17/unregisterCapability.md

A sample JSON-RPC payload for unregistering the textDocument/willSaveWaitUntil capability.

```json
{
	"method": "client/unregisterCapability",
	"params": {
		"unregisterations": [
			{
				"id": "79eee87c-c409-4664-8102-e03263673f6f",
				"method": "textDocument/willSaveWaitUntil"
			}
		]
	}
}
```

--------------------------------

### Example TypeScript Diagnostic Input

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Sample TypeScript code used to generate diagnostic output.

```typescript
function foo() {
  let x: string = 10;
}
```

--------------------------------

### Initiating Work Done Progress

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/types/workDoneProgress.md

Work Done progress can be initiated in two different ways: client-initiated using `workDoneToken` or server-initiated using the `window/workDoneProgress/create` request.

```APIDOC
## Initiating Work Done Progress

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.
```

--------------------------------

### Emitted Vertex Structure for Function

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

The resulting vertex structure for the provided hello function example.

```typescript
{ id: 2, type: "vertex", label: "document",
  uri: "file:///Users/dirkb/sample.ts", languageId: "typescript"
}
{ id: 4, type: "vertex", label: "resultSet" }
{ id: 7, type: "vertex", label: "range",
  start: { line: 0, character: 9 }, end: { line: 0, character: 14 },
  tag: {
    type: "definition", text: "hello", kind: 12,
    fullRange: {
      start: { line: 0, character: 0 }, end: { line: 1, character: 1 }
    }
  }
}
```

--------------------------------

### initialize Request

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/general/initialize.md

The initialize request is sent as the first request from the client to the server to establish the session.

```APIDOC
## initialize

### Description
The initialize request is sent as the first request from the client to the server. Until the server has responded with an InitializeResult, the client must not send any additional requests or notifications.

### Method
Request

### Request Body
- **processId** (integer | null) - Required - The process Id of the parent process that started the server.
- **clientInfo** (object) - Optional - Information about the client.
- **locale** (string) - Optional - The locale the client is currently showing the user interface in.
- **rootPath** (string | null) - Optional - The rootPath of the workspace (deprecated).
- **rootUri** (DocumentUri | null) - Required - The rootUri of the workspace.
- **initializationOptions** (LSPAny) - Optional - User provided initialization options.
- **capabilities** (ClientCapabilities) - Required - The capabilities provided by the client.
- **trace** (TraceValue) - Optional - The initial trace setting.
- **workspaceFolders** (WorkspaceFolder[] | null) - Optional - The workspace folders configured in the client.

### Request Example
{
	"processId": 1234,
	"rootUri": "file:///path/to/workspace",
	"capabilities": {}
}
```

--------------------------------

### Range Interface Definition

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/types/range.md

Defines the structure of a Range object, which consists of a start and end position.

```APIDOC
## Range Interface

### Description
A range in a text document expressed as (zero-based) start and end positions. A range is comparable to a selection in an editor. The end position is exclusive.

### Structure
- **start** (Position) - The range's start position.
- **end** (Position) - The range's end position.

### Example
{
    "start": { "line": 5, "character": 23 },
    "end": { "line": 6, "character": 0 }
}
```

--------------------------------

### Range Interface Definition

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/types/range.md

Defines the structure of a Range object, including start and end positions.

```typescript
interface Range {
	/**
	 * The range's start position.
	 */
	start: Position;

	/**
	 * The range's end position.
	 */
	end: Position;
}
```

--------------------------------

### POST workspace/executeCommand

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/workspace/executeCommand.md

Triggers a command execution on the server side.

```APIDOC
## POST workspace/executeCommand

### Description
The `workspace/executeCommand` request is sent from the client to the server to trigger command execution on the server.

### Method
POST

### Endpoint
workspace/executeCommand

### Parameters
#### Request Body
- **command** (string) - Required - The identifier of the actual command handler.
- **arguments** (LSPAny[]) - Optional - Arguments that the command should be invoked with.

### Request Example
{
	"command": "my.command",
	"arguments": ["arg1", 123]
}

### Response
#### Success Response (200)
- **result** (LSPAny) - The result of the command execution.
```

--------------------------------

### Define LSIF project and document vertices

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

Example of emitting project and document vertices with a contains edge.

```typescript
{ id: 1, type: "vertex", label: "project",
  resource: "file:///Users/dirkb/tsconfig.json", kind: "typescript"
}
{ id: 2, type: "vertex", label: "document",
  uri: "file:///Users/dirkb/sample.ts", languageId: "typescript"
}
{ id: 3, type: "edge", label: "contains", outV: 1, inVs: [2] }
```

--------------------------------

### textDocument/implementation

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/language/implementation.md

The go to implementation request is sent from the client to the server to resolve the implementation location of a symbol at a given text document position.

```APIDOC
## textDocument/implementation

### Description
The go to implementation request is sent from the client to the server to resolve the implementation location of a symbol at a given text document position.

### Method
textDocument/implementation

### Parameters
#### Request Body
- **textDocument** (TextDocumentIdentifier) - Required - The text document.
- **position** (Position) - Required - The position inside the text document.
- **workDoneToken** (ProgressToken) - Optional - An optional token that a server can use to report work done progress.
- **partialResultToken** (ProgressToken) - Optional - An optional token that a server can use to report partial results.

### Response
#### Success Response
- **result** (Location | Location[] | LocationLink[] | null) - The implementation location(s) or null if none found.
- **partialResult** (Location[] | LocationLink[]) - Partial result of the implementation locations.
```

--------------------------------

### Example TypeScript Source for Symbol Emission

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

A simple function declaration used to demonstrate how tags are emitted.

```typescript
function hello() {
}

hello();
```

--------------------------------

### Server Initiated Progress

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/types/workDoneProgress.md

Details how servers can initiate progress reporting for operations that are not tied to a specific client request, using the `window/workDoneProgress/create` request.

```APIDOC
## Server Initiated Progress

### Description
Servers can initiate progress reporting for tasks not directly linked to a client request, such as re-indexing a database. This is achieved via the `window/workDoneProgress/create` request.

### Client Capability
Clients must signal support for server-initiated progress.

```typescript
{
	"window": {
		"workDoneProgress": true
	}
}
```

### Server Request to Create Progress Token
Servers request a token from the client to report progress.

### Endpoint
`window/workDoneProgress/create`

### Request Body
(Example not provided in source, but would contain a token)

### Response
(Example not provided in source, but would contain a token)

### Progress Notification (using the created token)
Servers use the token obtained from `window/workDoneProgress/create` to send progress notifications similar to client-initiated progress (`$/progress`). The token should be used for a single progress lifecycle (begin, report, end).
```

--------------------------------

### SignatureHelpOptions Interface

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/language/signatureHelp.md

Defines options for a signature help provider. Use this to specify characters that trigger signature help automatically or re-trigger it when already showing.

```typescript
export interface SignatureHelpOptions extends WorkDoneProgressOptions {
	/**
	 * The characters that trigger signature help
	 * automatically.
	 */
	triggerCharacters?: string[];

	/**
	 * List of characters that re-trigger signature help.
	 *
	 * These trigger characters are only active when signature help is already
	 * showing. All trigger characters are also counted as re-trigger
	 * characters.
	 *
	 @since 3.15.0
	 */
	retriggerCharacters?: string[];
}
```

--------------------------------

### window/workDoneProgress/create

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/window/workDoneProgressCreate.md

The server sends this request to the client to create a work done progress indicator.

```APIDOC
## POST /window/workDoneProgress/create

### Description
Sends a request from the server to the client to create a work done progress indicator.

### Method
POST

### Endpoint
/window/workDoneProgress/create

### Parameters
#### Request Body
- **token** (ProgressToken) - Required - The token to be used to report progress.

### Request Example
```json
{
  "token": "some-progress-token"
}
```

### Response
#### Success Response (200)
- **result** (void) - Indicates successful creation of the progress indicator.

#### Error Response
- **error** (ResponseError) - Contains code and message if an exception occurs during the request. The server must not send any progress notifications using the provided token if an error occurs.
```

--------------------------------

### LSIF Vertex and Edge Definitions

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

JSON-like vertex and edge definitions representing the reference results for the TypeScript example.

```json
// The document
{ id: 4, type: "vertex", label: "document",
  uri: "file:///Users/dirkb/sample.ts", languageId: "typescript"
}

// Declaration of I#foo
{ id: 13, type: "vertex", label: "resultSet" }
{ id: 16, type: "vertex", label: "range",
  start: { line: 1, character: 2 }, end: { line: 1, character: 5 }
}
{ id: 17, type: "edge", label: "next", outV: 16, inV: 13 }

// Declaration of II#foo
{ id: 27, type: "vertex", label: "resultSet" }
{ id: 30, type: "vertex", label: "range",
  start: { line: 5, character: 2 }, end: { line: 5, character: 5 }
}
{ id: 31, type: "edge", label: "next", outV: 30, inV: 27 }

// Declaration of B#foo
{ id: 45, type: "vertex", label: "resultSet" }
{ id: 52, type: "vertex", label: "range",
  start: { line: 9, character: 2 }, end: { line: 9, character: 5 }
}
{ id: 53, type: "edge", label: "next", outV: 52, inV: 45 }

// Reference result for I#foo
{ id: 46, type: "vertex", label: "referenceResult" }
{ id: 47, type: "edge", label: "textDocument/references", outV: 13, inV: 46 }

// Reference result for II#foo
{ id: 48, type: "vertex", label: "referenceResult" }
{ id: 49, type: "edge", label: "textDocument/references", outV: 27, inV: 48 }

// Reference result for B#foo
{ id: 116 "typ" :"vertex", label: "referenceResult" }
{ id: 117 "typ" :"edge", label: "textDocument/references", outV: 45, inV: 116 }

// Link B#foo reference result to I#foo and II#foo
{ id: 118 "typ" :"edge", label: "item",
  outV: 116, inVs: [46,48], document: 4, property: "referenceResults"
}
```

--------------------------------

### POST workspace/inlayHint/refresh

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/language/inlayHint.md

Sent from the server to the client to request a refresh of all inlay hints currently shown in editors.

```APIDOC
## POST workspace/inlayHint/refresh

### Description
The `workspace/inlayHint/refresh` request is sent from the server to the client to ask clients to refresh the inlay hints currently shown in editors. This is useful if a server detects a configuration change which requires a re-calculation of all inlay hints.

### Method
POST

### Endpoint
workspace/inlayHint/refresh

### Parameters
- **params** (none) - None

### Response
#### Success Response (200)
- **result** (void) - Request acknowledged.

#### Error Response
- **error** (object) - Code and message set in case an exception happens during the request.
```

--------------------------------

### Request with Partial Result Token

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/types/partialResults.md

Example of a request parameter object including both workDoneToken and partialResultToken for progress reporting.

```json
{
	"textDocument": {
		"uri": "file:///folder/file.ts"
	},
	"position": {
		"line": 9,
		"character": 5
	},
	"context": {
		"includeDeclaration": true
	},
	// The token used to report work done progress.
	"workDoneToken": "1d546990-40a3-4b77-b134-46622995f6ae",
	// The token used to report partial result progress.
	"partialResultToken": "5f6f349e-4f81-4a3b-afff-ee04bff96804"
}
```

--------------------------------

### NotebookDocumentSyncClientCapabilities

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/notebookDocument/notebook.md

Client capabilities for notebook document synchronization.

```APIDOC
## NotebookDocumentSyncClientCapabilities

### Description
Defines the capabilities supported by the client regarding notebook document synchronization.

### Properties
- **dynamicRegistration** (boolean) - Optional - Whether the client supports dynamic registration.
- **executionSummarySupport** (boolean) - Optional - Whether the client supports sending execution summary data per cell.
```

--------------------------------

### Markup Kinds for Content Formatting

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/types/markupContent.md

Defines constants for supported content formats: plaintext and markdown. These kinds should not start with '$'.

```typescript
/**
 * Describes the content type that a client supports in various
 * result literals like `Hover`, `ParameterInfo` or `CompletionItem`.
 *
 * Please note that `MarkupKinds` must not start with a `$`. This kinds
 * are reserved for internal usage.
 */
export namespace MarkupKind {
	/**
	 * Plain text is supported as a content format
	 */
	export const PlainText: 'plaintext' = 'plaintext';

	/**
	 * Markdown is supported as a content format
	 */
	export const Markdown: 'markdown' = 'markdown';
}
export type MarkupKind = 'plaintext' | 'markdown';
```

--------------------------------

### Initialize Request Capabilities

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/general/initialize.md

Defines the client capabilities sent during the initialization phase of the Language Server Protocol.

```APIDOC
## Client Capabilities

### Description
Defines the capabilities the client supports, including notebook documents, window features, and general settings.

### Request Body
- **notebookDocument** (NotebookDocumentClientCapabilities) - Optional - Capabilities specific to notebook document support.
- **window** (Object) - Optional - Window specific client capabilities.
  - **workDoneProgress** (boolean) - Optional - Indicates support for server-initiated progress.
  - **showMessage** (ShowMessageRequestClientCapabilities) - Optional - Capabilities for showMessage request.
  - **showDocument** (ShowDocumentClientCapabilities) - Optional - Capabilities for showDocument request.
- **general** (Object) - Optional - General client capabilities.
  - **staleRequestSupport** (Object) - Optional - Configuration for handling stale requests.
  - **regularExpressions** (RegularExpressionsClientCapabilities) - Optional - Capabilities for regular expressions.
  - **markdown** (MarkdownClientCapabilities) - Optional - Capabilities for markdown parser.
  - **positionEncodings** (PositionEncodingKind[]) - Optional - Supported position encodings.
- **experimental** (LSPAny) - Optional - Experimental client capabilities.
```

--------------------------------

### Emitted Vertex Structure for Namespace

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsif/0.6.0/specification.md

The resulting vertex structure for the namespace example, including children and document symbol results.

```typescript
// The document
{ id: 2 , type: "vertex", label: "document",
  uri: "file:///Users/dirkb/sample.ts", languageId: "typescript"
}
// The declaration of Main
{ id: 7 , type: "vertex", label: "range",
  start: { line: 0, character: 10 }, end: { line: 0, character: 14 },
  tag: {
    type: "definition", text: "Main", kind: 7,
    fullRange: {
      start: { line: 0, character: 0 }, end: { line: 5, character: 1 }
    }
  }
}
// The declaration of hello
{ id: 18 , type: "vertex", label: "range",
  start: { line: 1, character: 11 }, end: { line: 1, character: 16 },
  tag: {
    type: "definition", text: "hello", kind: 12,
    fullRange: {
      start: { line: 1, character: 2 }, end: { line: 2, character: 3 }
    }
  }
}
// The declaration of world
{ id: 29 , type: "vertex", label: "range",
  start: { line: 3, character: 11 }, end: { line: 3, character: 16 },
  tag: {
    type: "definition", text: "world", kind: 12,
    fullRange: {
      start: { line: 3, character: 2 }, end: { line: 4, character: 3 }
    }
  }
}
// The document symbol
{ id: 39 , type: "vertex", label: "documentSymbolResult",
  result: [ { id: 7 , children: [ { id: 18 }, { id: 29 } ] } ]
}
{ id: 40 , type: "edge", label: "textDocument/documentSymbol",
```

--------------------------------

### Inlay Hints Provider

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/general/initialize.md

Configuration for inlay hints support.

```APIDOC
## Inlay Hints Provider

### Description
The server provides inlay hints.

@since 3.17.0

### Parameters
#### Request Body
- **inlayHintProvider** (boolean | InlayHintOptions | InlayHintRegistrationOptions) - Optional - The server provides inlay hints.
```

--------------------------------

### Declaration Client Capabilities

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/language/declaration.md

Defines the capabilities of a client to support the goto declaration request. Use this to indicate if dynamic registration or link support is available.

```typescript
export interface DeclarationClientCapabilities {
	/**
	 * Whether declaration supports dynamic registration. If this is set to
	 * `true` the client supports the new `DeclarationRegistrationOptions`
	 * return value for the corresponding server capability as well.
	 */
	dynamicRegistration?: boolean;

	/**
	 * The client supports additional metadata in the form of declaration links.
	 */
	linkSupport?: boolean;
}
```

--------------------------------

### Define ImplementationRegistrationOptions

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/language/implementation.md

Interface for registration options, combining text document, implementation, and static registration capabilities.

```typescript
export interface ImplementationRegistrationOptions extends
	TextDocumentRegistrationOptions, ImplementationOptions,
	StaticRegistrationOptions {
}
```

--------------------------------

### JavaScript Function Definition

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/notebookDocument/notebook.md

A simple JavaScript function to add two numbers. This is an example of cell content within a notebook.

```javascript
function add(a, b) {
	return a + b;
}
```

--------------------------------

### FoldingRange Type Definition

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/language/foldingRange.md

Defines the structure for a folding range, including start and end positions, kind, and collapsed text.

```APIDOC
## FoldingRange Type

### Description
Represents a range that can be folded in the editor.

### Properties
- **startCharacter** (uinteger) - Optional - The character where the folding range starts. Defaults to the length of the end line.
- **endCharacter** (uinteger) - Optional - The character where the folding range ends. Defaults to the length of the end line.
- **kind** (FoldingRangeKind) - Optional - Describes the kind of the folding range (e.g., 'comment', 'region').
- **collapsedText** (string) - Optional - The text to display when the range is collapsed. (Introduced in 3.17.0 - proposed)
```

--------------------------------

### NotebookDocumentSyncOptions

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/notebookDocument/notebook.md

Configuration options for syncing notebook documents and their cells to the server.

```APIDOC
## NotebookDocumentSyncOptions

### Description
Options specific to a notebook plus its cells to be synced to the server.

### Parameters
#### Request Body
- **notebookSelector** (Array) - Required - The notebooks to be synced.
- **save** (boolean) - Optional - Whether save notification should be forwarded to the server.
```

--------------------------------

### Text Document Hover Request

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_specifications/lsp/3.17/specification.md

A client-initiated request to get hover information for a symbol at a specific text document position.

```APIDOC
## Request: textDocument/hover

### Description
Requests hover information for a symbol at a given position in a text document.

### Method
POST

### Endpoint
/textDocument/hover

### Parameters
#### Request Body
- **params** (HoverParams) - Required - Parameters for the hover request.
  - **textDocument** (string) - Required - The URI of the text document.
  - **position** (object) - Required - The position in the text document.
    - **line** (uinteger) - Required - The line number.
    - **character** (uinteger) - Required - The character number.

### Request Example
```json
{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "textDocument/hover",
  "params": {
    "textDocument": "file:///path/to/your/document.txt",
    "position": {
      "line": 0,
      "character": 2
    }
  }
}
```

### Response
#### Success Response (200)
- **value** (string) - The hover information to be displayed. Can be null if no hover information is available.

#### Response Example
```json
{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "value": "This is the hover information."
  }
}
```

*Note: A `null` result indicates no hover information is available.*
```

--------------------------------

### client/registerCapability

Source: https://github.com/microsoft/language-server-protocol/blob/gh-pages/_includes/messages/3.17/registerCapability.md

The `client/registerCapability` request is sent from the server to the client to register for a new capability on the client side. Clients opt in via the `dynamicRegistration` property on their capabilities. A client can register for some capabilities dynamically and not for others.

```APIDOC
## POST client/registerCapability

### Description
Registers a new capability on the client side dynamically. This request is sent from the server to the client.

### Method
POST

### Endpoint
/client/registerCapability

### Parameters
#### Request Body
- **registrations** (Registration[]) - Required - An array of registrations for new capabilities.

### Request Example
```json
{
	"method": "client/registerCapability",
	"params": {
		"registrations": [
			{
				"id": "79eee87c-c409-4664-8102-e03263673f6f",
				"method": "textDocument/willSaveWaitUntil",
				"registerOptions": {
					"documentSelector": [
						{ "language": "javascript" }
					]
				}
			}
		]
	}
}
```

### Response
#### Success Response (200)
- **result** (void) - This request does not return a value upon success.

#### Error Response
- **error** (code and message) - Set in case an exception happens during the request.
```