×
Community Blog Quick Start to VSCode Plug-Ins: LSP protocol initialization parameters

Quick Start to VSCode Plug-Ins: LSP protocol initialization parameters

In this part of the tutorial series, you will learn how to build a running LSP system.

Quick Start to VSCode Plug-Ins: LSP protocol initialization parameters

By Xulun

After learning how to complete the LSP code, we can try to build a running LSP system. But before that, let's consolidate some things first. So we have introduced you the handshake process of LSP initialization previously in this tutorial series. Well, now we can receive the client's initialization parameters, such as the capabilities, in the connection's onInitialize function.

connection.onInitialize((params: InitializeParams) => {
    let capabilities = params.capabilities;

    return {
        capabilities: {
            textDocumentSync: documents.syncKind,
            // Tell the client that the server supports code completion
            completionProvider: {
                resolveProvider: true
            }
        }
    };
})

But, hang on, before we get too much into that, let's take a look at the content of the LSP initialization parameters with a diagram:

1

Now, let's take a look at these definitions:

interface InitializeParams {
    /**
     * The process Id of the parent process that started
     * the server. Is null if the process has not been started by another process.
     * If the parent process is not alive then the server should exit (see exit notification) its process.
     */
    processId: number | null;

    /**
     * The rootPath of the workspace. Is null
     * if no folder is open.
     *
     * @deprecated in favour of rootUri.
     */
    rootPath?: string | null;

    /**
     * The rootUri of the workspace. Is null if no
     * folder is open. If both `rootPath` and `rootUri` are set
     * `rootUri` wins.
     */
    rootUri: DocumentUri | null;

    /**
     * User provided initialization options.
     */
    initializationOptions?: any;

    /**
     * The capabilities provided by the client (editor or tool)
     */
    capabilities: ClientCapabilities;

    /**
     * The initial trace setting. If omitted trace is disabled ('off').
     */
    trace?: 'off' | 'messages' | 'verbose';

    /**
     * The workspace folders configured in the client when the server starts.
     * This property is only available if the client supports workspace folders.
     * It can be `null` if the client supports workspace folders but none are
     * configured.
     *
     * Since 3.6.0
     */
    workspaceFolders?: WorkspaceFolder[] | null;
}

We classify the above information, as shown in the following figure:

2

It can be mainly classified into the following three types of information:

  • Information related to the operating environment, such as information about the path and the process.
  • Capability information.
  • Some auxiliary information, such as trace settings and user-defined information.

The path information can only be obtained when a directory has been opened in the VSCode where the plug-in is running. So let's suppose the directory opened is /Users/ziyingliuziying/working/gitlab/cafmode/server, then the result returned by rootPath is /Users/ziyingliuziying/working/gitlab/cafmode/server. The result returned by rootUri is file:///Users/ziyingliuziying/working/gitlab/cafmode/server

Next, workspaceFolders is an array of WorkspaceFolder. Each WorkspaceFolder is an object composed of name and URI. Take the above example as an example: The name is "server" and the URI is file:///Users/ziyingliuziying/working/gitlab/cafmode/server

0 0 0
Share on

Louis Liu

7 posts | 0 followers

You may also like

Comments