Protocol extension to drive UI components

[michelkaporin]

👋 Have there been any attempts to provide an extension to the protocol to standardise UI contribution for LSP-based extension developers?

If not, is this planned or would it be possible to standardise it, should such an attempt be made?

Context The benefit of language server is that it's code editor/IDE independent. UI components are normally editor-specific, however there are certain presentational layer elements that are shared by many code editors. For instance, tree view components can often be implemented by different vendors (e.g. editors often have "File Outline" as tree view).

As an extension developer, it's hard to maintain such UIs per each IDE that are enabled via LSP. Another example of such is web view UI component, which allows extension developers to create fully customisable views.

[dbaeumer]

See also https://github.com/microsoft/language-server-protocol/issues/1164

[puremourning]

we need to be cautious of the inner platform effect here.

we also need to be careful not to make features that rely on capabilities of certain editors (such as having a "tree view"). It seems better to me for LSP to concentrate on abstractions, rather than complexities of concrete UI concepts.

[DanTup]

I posted some notes about what we've started trying out with Dart here:

https://github.com/microsoft/language-server-protocol/issues/1164#issuecomment-1328930377

It's intended to be editor-agnostic. The editor tells the server what kinds of parameters it can prompt the user for and they're just replaced into the arguments of the command that will be executed (by middleware in the VS Code extension, but it's intended that other editors extensions could do the same with whatever appropriate mechanisms they have for collecting input from a user).

[puremourning]

I still think that a better API doesn't ask anyone to "prompt" the user for anything. Rather a refactoring states its parameters, their types, say, and the editor/user/script/plugin/bot determines how to provide those to the server. The corollary is the rename request (which is a sort of special-cased code-action), where it has a defined parameter ("new name") and clients surface how to provide that however they choose. this comment applies to this issue and #1164

[DanTup]

@puremourning that's basically what I posted. The API above does not have the server drive any prompts - it provides the user with parameters and their kinds, and it's up to the client to handle getting user input and replacing the values in the arguments sent to the command.

The enumeration of those parameters and sequential prompting is entirely VS Code-specific stuff in some middleware. A client that supports dialogs could easily show a single dialog that collects all of that info in one step.

[puremourning]

The API above does not have the server drive any prompts - it provides the user with parameters and their kinds, and it's up to the client to handle getting user input and replacing the values in the arguments sent to the command.

Great - SGTM in principle! Sorry I sort of got all confused by the VScode-specific parts of your post over there :).

[DanTup]

Yeah sorry, the links to code were all in middleware because there isn't so much in the way of "spec" for the protocol.

The JSON for a CodeAction looks something like this:

{
    "kind": "refactor",
    "title": "Move 'main' to file",
    "command": {
        "arguments": [
            // For Dart, we generally pass arguments as an object so we can
            // provide names, so the arguments list here is a single item
            {
                // These arguments are not defined by parameters but are fixed
                "filePath": "/Users/danny/Desktop/dart_sample/bin/main.dart",
                "selectionOffset": 7,
                "selectionLength": 0,
                // These additional "arguments" can be overwritten by user-provided values
                // using the info in data.parameters 
                "arguments": [
                    "file:///Users/danny/Desktop/dart_sample/bin/main.dart"
                ]
            }
        ],
        "command": "move_top_level_to_file",
        "title": "Move 'main' to file"
    },
    "data": {
        // These parameters map to "arguments" above
        "parameters": [
            {
                "kind": "saveUri",
                "parameterTitle": "Select a file to move to",
                "parameterLabel": "Move to:",
                "defaultValue": "file:///Users/danny/Desktop/dart_sample/bin/main.dart",
                "actionLabel": "Move",
                "filters": {
                    "Dart": [
                        "dart"
                    ]
                }
            }
        ]
    }
}

The client uses data.parameters to drive any UI and replace values into the arguments list before the command is sent back to the server for execution.