Handle non-file URIs

[stexxart]

Is your feature request related to a problem? Please describe.
At the moment, Goto Definition does not work for remote ES modules that use the HTTP URI scheme. Deno projects import libraries directly from URLs and browser JavaScript projects have supported this for a long while. The current behaviour of Goto Definition shows an empty file.

Describe the solution you'd like
When wanting to go to the definition of a module I'd like to be able to view it's source directly in Sublime. It was suggested the file contents could be fetched and stored in a scratch buffer. It should also continue to work if import maps are being used.

Describe alternatives you've considered
VSCode can already do this. Specifically, the VSCode Deno extension supports this out of the box.

[rwols]

It should also continue to work if import maps are being used.

Does this mean the reported uri to the language server when opening the document should also have an http scheme? If we open it as a scratch buffer then we can't rely on view.file_name() anymore as being the "canonical" uri. Moreover currently we don't attach to views without a file name. Lots of challenges here.

[rwols]

I'm trying this out locally now and what you claim isn't actually true. The scheme is not http:// but deno:/.

:: --> Deno textDocument/implementation(4): {'position': {'character': 12, 'line': 0}, 'textDocument': {'uri': 'file:///Users/raoulwols/dev/denoserver/server.ts'}, 'workDoneToken': 'wd4'}
:: <<< Deno 4: [{'targetUri': 'deno:/https/deno.land/std/http/server.ts', 'targetRange': {'end': {'character': 1, 'line': 305}, 'start': {'character': 0, 'line': 298}}, 'targetSelectionRange': {'end': {'character': 21, 'line': 298}, 'start': {'character': 16, 'line': 298}}}]

So both server and client have IMO bugs.

1. Server should report proper http:// or https:// uris
2. Client should be able to open those uris

I'll be focussing on just http(s) schemes, not deno:/ schemes.

[rwols]

I'm looking into this a bit more and it's a custom protocol extension to show these kinds of documents. So vscode-specific client glue. 👎

https://github.com/denoland/vscode_deno/blob/34b7130f3b810a635f88dd88e5927f3faaa1bffa/client/src/lsp_extensions.ts

I guess the idea is to ask a plugin for the content of deno:/https/deno.land/std/http/server.ts. Such a plugin would then have to request deno/virtualTextDocument.

So you need an LSP-Deno helper package.

[rwols]

I have something working here :)

Schermopname.2021-03-11.om.22.23.53.mov

Still, LSP doesn't attach to such a view because it has no filename. That's another can of worms I guess.

[hronro]

@rwols Great. Can I expect we will have deno lsp integration in sublimelsp soon?

[rwols]

It’s done when it’s done.

[rwols]

A helper package called LSP-Deno will appear on packagecontrol.io soon. This will allow you to goto-def on remote files and find-references on remote files (only when using the quick panel variant presentation).

However LSP will not attach the language server to such remote files. I will close this issue and create new ones to make us focus more on the remaining issues.

[rwols]

#1739