Feature request: Expose the sync API to all client/server connections

[rchiodo]

I'm implementing this feature here:
https://github.com/microsoft/vscode-wasm/blob/main/sync-api-client/README.md
in pylance.

And it seems to me that this could be a common feature for just about every language server that uses vscode-languageserver.

Maybe something that would be exposed through a new capability.

Then on the server side you could use the new sync methods.

protected async getFileSystem() {
        return this._connection.workspace.getSyncFileSystem();
}

private _readFile(filePath: string) {
     const fs = this.getFileSystem();
    const bytes = fs.readFile(filePath);
    return this._decoder.decode(bytes, 'utf-8');
}

[dbaeumer]

Currently LSp doesn't expose any FS API that roots back to the client. There are feature requests to support this and when implementing it it would be cool to provide a sync and async variant.

[heejaechang]

so, we have this issue as well - microsoft/vscode#177391

Basically, currently LSP only provides us contents for opened files. For opened files, regular file, notebook file, file on github or browser, all works as expected since we get the content/uri from LSP and we don't need to care how we get them.

But, for closed files, for regular file on disk, we can open them and read the content. and we know how to construct uri for the file ourselves that LSP client also know how to interpret. but problem is for any other cases.

For example, for closed notebook file, we are not sure how we can get contents (of each cells and metadata) and uri from them. same for files (regular or notebook) on virtual workspace or browser (basically files that are not on disks). we are not sure how we should obtain contents and uri for them.

It feels like the root cause of all this issue is that LSP only cares about open files. and feels like now it is time for LSP to provide some APIs for closed files as well.

and when it does, it would be nice if it provides both async and sync APIs for sync and async LS servers.

[heejaechang]

Requesting each Language Server (LS) to implement handling for closed file cases (such as reading notebooks, constructing URIs according to each client's preferences for notebook cells, accessing GitHub/HTTP and creating synchronous APIs and etc) seems to be asking each LS to reinvent the wheel multiple times. Particularly, if an LSP client can manage open files, it likely indicates that they already know how to read content and creates URIs from those files.

[dbaeumer]

I agree with all of this. @NTaylorMullen started to provide a FS layer inside LSP but we never got it over the finish line :-(. Help is welcome to continue the work on this.

[r3m0t]

Would it need to be added to LSP at the same time or is it VS Code specific? @dbaeumer

[rchiodo]

I can help out on implementing this. If this was in vscode-languageserver, we wouldn't need to implement it ourselves. So we might as well implement it for everybody.

@NTaylorMullen and @dbaeumer do you want to meetup to discuss what this might look like?