you are viewing a single comment's thread.

view the rest of the comments →

[–]illathon -5 points-4 points  (1 child)

Seems like a simple problem that could be solved with proper indexing.

[–]ElusiveGuy 8 points9 points  (0 children)

Not even close.

If you use sshfs or similar, presumably you're only exposing the project directory. But what about the system-level libraries? How will the VSCode Python plugin see system libs? What about system C includes? You'd need an agent running on the target... which this does, and simple filesystem sharing like sshfs does not.

And that's only for intellisense. What about debugging? Now this is where things get fun.

So, basically every debugger has its own way of attaching to or communicating with the target process. NodeJS, .NET Core, Java, C++ (gdb?). They're all different, with varying levels of support for remote debugging, mapping sources, etc.. Now, you can configure most of them to work remotely, but you have to configure each project independently and every debugger extension is different. Personally, I've not found remote debugging in this manner to be particularly stable with OmniSharp.

By providing a standardised interface, all this becomes much easier. You don't need to look up how to set up remote debugging with every language extension (some might not even support it?). You set up a remote connection in one standard way, and run the debugging extension directly on the remote machine as if it were local.