Cross server communication

The current state of inter lsp servers communication leaves much to be desired. Indeed there are embedded language services and request forwarding, but these

• Are for embedded contents
• Are not LSP client agnostic (require the use of vscode APIs)

Since the goal of the LSP is to provide access to any language's parsed and analyzed content in a standard way, I believe that it should be the language server's job to get all the information it needs through the other language servers.

Possible solutions

1. Get the running LSP server addresses with their corresponding language.

• During initialization, the server says it will need access to the LSP server for languageID.
• The client sends the other language's server address in every request.
• The server can then fetch this other server for all the data it needs.

2. The data is requested through the client, which acts as a Proxy.

• A method from the server can be forwarded to the other language server, by sending an englobing request:

{
  method: "forward/css", // or any other language id
  params: {
    method: "some/forwarded/method",
    params: {
      // ...
    }
}

With this solution, two servers can communicate one with the other without having to implement any of the client functionality.

Examples

VHDL <-> Verilog <-> System Verilog

These can be used together without bindings, and language servers fail to resolve available variables coming from other languages, even though they are available. This would be fixed by asking the other language servers for the variables they export.

JS <- JSON

Currently, AFAIK there is no JSON LSP, but reading JSON is embedded into the JS LSP. That means when a json file is imported, we get autocompletion for its data from within JS.

However, did we have a language server specifically for JSON, there would be no way to get the available keys for the JS LSP server, without it reimplementing the JS functionality.

The case of all bindings based inter language communication:

• C -> Rust uses bindgen
• Rust -> C uses cbindgen
• C -> Python : v a r i o u s options
• All languages with a foreign function interface

All of these break the single source of truth principle by creating bindings, but at least they get editor auto complete. This may be a viable option for some languages, but definitely not for all.

... To be continued, will write more tomorrow.

No repository files, tests, or entry points are named. Start by reading the linked VS Code embedded-language documentation and compare the two proposed communication models and the VHDL, Verilog, SystemVerilog, JavaScript, and JSON examples; completion would require an agreed protocol design rather than a scoped implementation.