---
title: "Get code segment information"
method: POST
path: "/v1/devboxes/{id}/lsp/get-code-segment-info"
tags: ["rl-language-service"]
---

# Get code segment information

`POST /v1/devboxes/{id}/lsp/get-code-segment-info`

Get the symbol, reference, and diagnostic information for a given code segment in a file at a given depth

## Path parameters

- `id` string, required

## Request body

- CodeSegmentInfoRequestBody
  - `symbolType` 'function' | 'variable' | 'class' | 'interface' | 'type'
  - `uri` string, required
  - `symbolName` string, required

## Response `200`

The symbol information, file URI, references, and diagnostics for the code segment, signatrue, and hover information

- CodeSegmentInfoResponse — Response for getting the code segment information for a given symbol in a file including symbol information, references, diagnostics, and actions for the code segment
  - `signature` SignatureHelpResponse
    - `activeParameter` number, double
    - `activeSignature` number, double
    - `signatures` BaseSignature[], required
      - `documentation` union
        - string
        - BaseMarkupContent
          - `value` string, required
          - `kind` string, required
      - `parameters` BaseParameterInformation[]
        - `documentation` union
          - string
          - BaseMarkupContent
            - `value` string, required
            - `kind` string, required
        - `label` string, required
      - `label` string, required
  - `hover` object
    - `range` BaseRange
      - `end` object, required
        - `character` number, double, required
        - `line` number, double, required
      - `start` object, required
        - `character` number, double, required
        - `line` number, double, required
    - `contents` unknown, required
  - `actions` BaseCodeAction[], required
    - `kind` string
    - `isPreferred` boolean
    - `command` BaseCommand
      - `arguments` unknown[]
        - unknown
      - `command` string, required
      - `title` string, required
    - `edit` BaseWorkspaceEdit
      - `changes` RecordStringTextEditArray — Construct a type with a set of properties K of type T
    - `title` string, required
  - `diagnostics` BaseDiagnostic[], required
    - `code` union
      - number, double
      - string
    - `source` string
    - `message` string, required
    - `severity` 1 | 2 | 3 | 4 — The diagnostic's severity.
    - `range` BaseRange, required
      - `end` object, required
        - `character` number, double, required
        - `line` number, double, required
      - `start` object, required
        - `character` number, double, required
        - `line` number, double, required
  - `references` BaseLocation[], required
    - `range` BaseRange, required
      - `end` object, required
        - `character` number, double, required
        - `line` number, double, required
      - `start` object, required
        - `character` number, double, required
        - `line` number, double, required
    - `uri` string, required
  - `uri` string, required
  - `symbol` DocumentSymbol, required — Represents programming constructs like variables, classes, interfaces etc. that appear in a document. Document symbols can be hierarchical and they have two ranges: one that encloses its definition and one that points to its most interesting range, e.g. the range of an identifier.
    - `name` string, required — The name of this symbol. Will be displayed in the user interface and therefore must not be an empty string or a string only consisting of white spaces.
    - `detail` string — More detail for this symbol, e.g the signature of a function.
    - `kind` 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26, required — A symbol kind.
    - `tags` SymbolTag[] — Tags for this document symbol.
    - `deprecated` boolean — Indicates if this symbol is deprecated.
    - `range` Range, required — A range in a text document expressed as (zero-based) start and end positions. 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: ```ts { start: { line: 5, character: 23 } end : { line 6, character : 0 } } ``` The Range namespace provides helper functions to work with {@link Range} literals.
      - `start` Position, required — Position in a text document expressed as zero-based line and character offset. Prior to 3.17 the offsets were always based on a UTF-16 string representation. So 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. Since 3.17 clients and servers can agree on a different string encoding representation (e.g. UTF-8). The client announces it's supported encoding via the client capability [`general.positionEncodings`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#clientCapabilities). The value is an array of position encodings the client supports, with decreasing preference (e.g. the encoding at index `0` is the most preferred one). To stay backwards compatible the only mandatory encoding is UTF-16 represented via the string `utf-16`. The server can pick one of the encodings offered by the client and signals that encoding back to the client via the initialize result's property [`capabilities.positionEncoding`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#serverCapabilities). If the string value `utf-16` is missing from the client's capability `general.positionEncodings` servers can safely assume that the client supports UTF-16. If the server omits the position encoding in its initialize result the encoding defaults to the string value `utf-16`. Implementation considerations: since the conversion from one encoding into another requires the content of the file / line the conversion is best done where the file is read which is usually on the server side. Positions are line end character agnostic. So you can not specify a position that denotes `\r|\n` or `\n|` where `|` represents the character offset. The Position namespace provides helper functions to work with {@link Position} literals.
        - `line` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
        - `character` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
      - `end` Position, required — Position in a text document expressed as zero-based line and character offset. Prior to 3.17 the offsets were always based on a UTF-16 string representation. So 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. Since 3.17 clients and servers can agree on a different string encoding representation (e.g. UTF-8). The client announces it's supported encoding via the client capability [`general.positionEncodings`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#clientCapabilities). The value is an array of position encodings the client supports, with decreasing preference (e.g. the encoding at index `0` is the most preferred one). To stay backwards compatible the only mandatory encoding is UTF-16 represented via the string `utf-16`. The server can pick one of the encodings offered by the client and signals that encoding back to the client via the initialize result's property [`capabilities.positionEncoding`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#serverCapabilities). If the string value `utf-16` is missing from the client's capability `general.positionEncodings` servers can safely assume that the client supports UTF-16. If the server omits the position encoding in its initialize result the encoding defaults to the string value `utf-16`. Implementation considerations: since the conversion from one encoding into another requires the content of the file / line the conversion is best done where the file is read which is usually on the server side. Positions are line end character agnostic. So you can not specify a position that denotes `\r|\n` or `\n|` where `|` represents the character offset. The Position namespace provides helper functions to work with {@link Position} literals.
        - `line` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
        - `character` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
    - `selectionRange` Range, required — A range in a text document expressed as (zero-based) start and end positions. 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: ```ts { start: { line: 5, character: 23 } end : { line 6, character : 0 } } ``` The Range namespace provides helper functions to work with {@link Range} literals.
      - `start` Position, required — Position in a text document expressed as zero-based line and character offset. Prior to 3.17 the offsets were always based on a UTF-16 string representation. So 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. Since 3.17 clients and servers can agree on a different string encoding representation (e.g. UTF-8). The client announces it's supported encoding via the client capability [`general.positionEncodings`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#clientCapabilities). The value is an array of position encodings the client supports, with decreasing preference (e.g. the encoding at index `0` is the most preferred one). To stay backwards compatible the only mandatory encoding is UTF-16 represented via the string `utf-16`. The server can pick one of the encodings offered by the client and signals that encoding back to the client via the initialize result's property [`capabilities.positionEncoding`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#serverCapabilities). If the string value `utf-16` is missing from the client's capability `general.positionEncodings` servers can safely assume that the client supports UTF-16. If the server omits the position encoding in its initialize result the encoding defaults to the string value `utf-16`. Implementation considerations: since the conversion from one encoding into another requires the content of the file / line the conversion is best done where the file is read which is usually on the server side. Positions are line end character agnostic. So you can not specify a position that denotes `\r|\n` or `\n|` where `|` represents the character offset. The Position namespace provides helper functions to work with {@link Position} literals.
        - `line` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
        - `character` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
      - `end` Position, required — Position in a text document expressed as zero-based line and character offset. Prior to 3.17 the offsets were always based on a UTF-16 string representation. So 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. Since 3.17 clients and servers can agree on a different string encoding representation (e.g. UTF-8). The client announces it's supported encoding via the client capability [`general.positionEncodings`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#clientCapabilities). The value is an array of position encodings the client supports, with decreasing preference (e.g. the encoding at index `0` is the most preferred one). To stay backwards compatible the only mandatory encoding is UTF-16 represented via the string `utf-16`. The server can pick one of the encodings offered by the client and signals that encoding back to the client via the initialize result's property [`capabilities.positionEncoding`](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#serverCapabilities). If the string value `utf-16` is missing from the client's capability `general.positionEncodings` servers can safely assume that the client supports UTF-16. If the server omits the position encoding in its initialize result the encoding defaults to the string value `utf-16`. Implementation considerations: since the conversion from one encoding into another requires the content of the file / line the conversion is best done where the file is read which is usually on the server side. Positions are line end character agnostic. So you can not specify a position that denotes `\r|\n` or `\n|` where `|` represents the character offset. The Position namespace provides helper functions to work with {@link Position} literals.
        - `line` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
        - `character` number, double, required — Defines an unsigned integer in the range of 0 to 2^31 - 1.
    - `children` DocumentSymbol[] — Children of this symbol, e.g. properties of a class.

---

[API](https://skmtc.dev/runloopai/apis/runloop-api.md) · [All operations](https://skmtc.dev/runloopai/apis/runloop-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/runloopai/runloop-api/revisions/0cb966ca566f/schema)