Hello again. I’m building an extension against the Deno LSP. Getting code definitions for local files works, but getting definitions for external modules doesn’t.
The Deno LSP sends back targetUris that look like this: deno:/https/deno.land/x/vscode_languageserver_types%40v0.1.0/mod.ts. The idea is that you then send a deno/virtualTextDocument request to the Deno LSP, which returns a string you can open up in the editor.
Given that there’s no way to override the built-in handling of this LSP request, what would be the best way to proceed? Lobby for a way to override Nova’s default language client handling?
I’ve recently begun to contribute to the Deno extension, and we’re looking into features which would benefit from this capability. It would be great that it were added.
It would be great if LanguageClient.onRequest would be able to override Nova’s default handling, so that I could intercept responses to textDocument.definition requests and be able to display definitions for dependencies in Deno.
As a potential alternative to allowing arbitrary LSP requests to be overridden by extensions, would the ability for extensions to resolve “unknown” document URIs into something that is known be sufficient? (e.g. the Deno extension could register a “resolver” that, when Nova encounters a deno: URI, would ask it to resolve that into something it can open (e.g. a file on disk, a textual blob to open, etc.)
That would be pretty much ideal! I just assumed overriding the handling was the smaller and more moderate ask
The definition source itself is retrieved from another request to the Deno LSO with the target URI, so as long as this new method wouldn’t rely on something being on disk…
