Figure out how to jump to files in zip/jar/.class files

[olafurpg]

See comment from @gabro https://github.com/scalameta/language-server/pull/23/files#r150784897

Just as a comparison, the Java LSP jumps to a .class file containing the source.
I'm not sure I understand the implementation, but here's the relevant bit https://github.com/eclipse/eclipse.jdt.ls/blob/2127f12fb3700dd783b75d973e4f2ecc134b9ddf/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/NavigateToDefinitionHandler.java#L52

[olafurpg]

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.

[laughedelic]

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

[gabro]

But this functionality is not part of vscode as far as I know.

You mean LSP?

[olafurpg]

Yes @gabro ! I meant LSP.

[laughedelic]

Related: atom/ide-java#42. It just doesn't work now in Atom.

[olafurpg]

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.

[laughedelic]

Crosslinking, so that you can vote it up: microsoft/language-server-protocol#335

[olafurpg]

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.

[olafurpg]

VS Code 1.25.0 had updates on "Readonly file system provider" https://code.visualstudio.com/updates/v1_25#_readonly-file-system-provider

[olafurpg]

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.