non-canonical URIs for editor files

[jurgenvinju]

Describe the bug

• the LSPs (rascal and parametrized) receives absolute file:/// paths to identify the file in an editor
• most DSL implementors use getPathConfig with project URIs in there.
• this way for the same file two routes can exist inside summaries and other loc based data such as typepal models
• but queries won't match like this, the URIs are different sometimes accidentally and this breaks features such as reference resolution.

Perhaps we could address this by normalizing files in the workspace to project before they go into the Rascal callbacks? This is what the Eclipse plugin does as well.

[DavyLandman]

I don't understand your proposal directly, but we might have to go the other route, as VS Code doesn't understand project locs. So we can't be reporting diagnostics/jumping to definitions on project locs.

I agree we have to think about what to do with these files, but VS Code file system has no concept of aliased locs, so we can't tell it that project://X/src/main/rascal/B.rsc is the same file as file:///tmp/X/src/main/rascal/B.rsc and it will open a different editor for that (and not highlight it in the solution/project view.

[jurgenvinju]

I'm thinking we might canonicalize when the URI comes in from the LSP client, so file->project (when possible!), and then on the way back let the LSP server rewrite all project URIs back to file URIs. That way the client does not need to ask again what a project URI means to the server, and in the Rascal world all lookups in maps and relations work fine.

We have to serialize the URI anyway to JSON, might as well rewrite them?

I have no alternative solutions in mind yet. I'd rather choose between two or three alternative fixes than just go for the one that came to mind first.

[jurgenvinju]

There is an option to register a clone of the project scheme with VScode and implement that in TypeScript, and canonicalize the editors file based on the current projects in the workspace. That is one alternative solution.

[DavyLandman]

There is an option to register a clone of the project scheme with VScode and implement that in TypeScript, and canonicalize the editors file based on the current projects in the workspace. That is one alternative solution.

VS Code does not allow virtual file systems in their project explorer. So we cannot make that work fluently.

I agree with exploring multiple options.

[jurgenvinju]

VS Code does not allow virtual file systems in their project explorer. So we cannot make that work fluently.

I don't understand yet the role of the project explorer in this story. Here we would change the URI of the editor only. But I think it will be a messy business anyway, probably causing file reloads and what not. Forget about it :-P need more and better alternatives..

[DavyLandman]

The only think what we could do is that every URI we give VS Code, be it via openEditor or via the hyperlink detector, we ask rascal to resolve it, and then send it to vs code. but if there are schemes that don't resolve files, but do map onto the same files, we cannot solve it. (which is what was proposed in the original issue, but would involve us growing the LSP bridge a bit). Note that for VS Code to function properly, we better resolve everything to file uri's, and not uplift file to project uris.

There is no way to do it from within the file system of VS Code.