Add support to open URI schemes with server-provided content#2890
Add support to open URI schemes with server-provided content#2890jwortmann wants to merge 11 commits into
Conversation
|
So it looks like a new version of the roslyn server was published, and I can see in the initialize response that it registers the Unfortunately I have no idea how to make the server emit URIs with that scheme. Perhaps anyone who knows more about C# could help me with a simple example how to trigger this? |
| return Promise.resolve(None) | ||
| title = urlparse(uri).path.split('/')[-1] | ||
| content = response['text'].replace('\r', '') | ||
| syntax = '' |
There was a problem hiding this comment.
According to microsoft/language-server-protocol#1994 (comment) the client is responsible to determine the language/syntax for the buffer. The only information that we have are the URI and the content, but I see no generic way to determine it just from the URI if it is for example something like generated-source:aca9a9c1-a993-4ae4-b5c0-1864392b4630.
Another comment at microsoft/language-server-protocol#1994 (comment) suggests that the editor extension (in VSCode) sets the language ID for a given URI scheme. So we could add this as a new config key that maps URI schemes to syntax names (Window.new_file takes the syntax name as a string). It seems that using scope:source.xxx also works, but is somewhat buggy, because the syntax name in the bottom right corner is bugged then (sublimehq/sublime_text#4449). But perhaps we could use sublime.find_syntax_by_scope API for that. So maybe it should be a URI scheme -> scope mapping in the config instead.
I still think that it is a mistake in the spec design to do it that way, because the language server should easily know the proper language ID for the document content that itself has generated. So it doesn't make much sense to me why it was designed how it is, but frankly we can't do anything about that.
LSP specs: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#workspace_textDocumentContent
It looks like support for this was recently added into
roslyn-language-serverfor theroslyn-source-generatedURI scheme, but as far as I can tell it hasn't landed in a release yet. Or at least the language server installed withdoesn't seem to register anything for that method. Therefore untested and draft PR for now.
Edit: According to https://www.nuget.org/packages/roslyn-language-server/#versions-body-tab the last release was 3 months ago, but the functionality was added only 3 weeks ago. So we'll have to wait for a new release first, if we want to test it with that server.
Sidenote:
Not sure whether this URI scheme (or in general server-provided content for custom URI schemes) is also relevant for links in hover popups, but perhaps we should refactor the code from
LSP/plugin/hover.py
Lines 314 to 345 in 17b2e67
for links in hover popups to call
Session.open_uri_asyncinstead, in order to reduce the code duplication. Then some parts which are currently specific to links in hover popups would need to be moved intoSession.open_uri_async, and it would also need to pass theviewas an argument. Although there could be multiple sessions running for the view, with the hover content merged from the different hoverProviders, so it's not clear which session to pick, or how to delegate the links to the correct session. Maybe the URI opening could alternatively refactored into a free function, possibly with the session(s) as another argument.But we could look into that later and do it in a separate PR. Maybe we could also encode the target for DocumentLinks directly into the URI (instead of using
quick-panel:DocumentLinkURI), similar to the encoded code actions inLSP/plugin/core/url.py
Lines 113 to 114 in 17b2e67
or even handle that differently (maybe just take the first valid response instead of listing the links in a quick panel if there are links from multiple sessions).