Closed olafurpg closed 5 years ago
It seems eclipse.jdt.ls returns URIs with the jdt
scheme https://github.com/eclipse/eclipse.jdt.ls/blob/2127f12fb3700dd783b75d973e4f2ecc134b9ddf/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/JDTUtils.java#L376
In editors like vscode it's possible to register a text content provider for a particular URI scheme, we use this in metadoc scalameta.org/metadoc/ for "semanticdb". But this functionality is not part of vscode LSP as far as I know.
I'm going to check how it works in Atom with the Java LSP plugin. And I'm not if it's related or not, but there is this: http://flight-manual.atom.io/hacking-atom/sections/handling-uris
But this functionality is not part of vscode as far as I know.
You mean LSP?
Yes @gabro ! I meant LSP.
Related: https://github.com/atom/ide-java/issues/42. It just doesn't work now in Atom.
We can have different implementations to handle sources in the classpath depending on the capabilities of the editor. The fallback implementation can use the current hack we have in master.
Crosslinking, so that you can vote it up: https://github.com/Microsoft/language-server-protocol/issues/335
Seems like the relevant part of the vscode api is https://code.visualstudio.com/docs/extensionAPI/vscode-api#workspace.registerTextDocumentContentProvider where we can register a provider for the "semanticdb" URI scheme.
VS Code 1.25.0 had updates on "Readonly file system provider" https://code.visualstudio.com/updates/v1_25#_readonly-file-system-provider
Fixed in #337. I ended up with writing to files on disk instead of the text content provider system in VS Code with the reasoning being that files work with all clients, not only VS Code.
I actually got the VS Code text content provider working but that opened a can of worms by having to handle metals://
URIs.
Files are written in the .metals/readonly/
directory and preserve the full path from the zip file: .metals/readonly/scala/Predef.scala
. The files are marked as read-only (not writable) on macOS/Linux so that users get an error if they try to edit the dependency sources. On Windows I hit on many problems using readonly files (AccessDeniedException
from just walking the file tree, not even readon) so I gave up and kept the files writable.
See comment from @gabro https://github.com/scalameta/language-server/pull/23/files#r150784897