Support for remote development scenarios

[jrieken]

Remote development describes a setup in which VS Code is used to edit files that reside on a different computer which file system cannot be mounted. A server that only offers FTP is an example of such a setup.

The following features should be supported for good dev experience

• see resources in the explorer, either as separate view or inline with the open folder/folders
• open (text) files, modify, save, and revert them. Lots of thoughts about this have been written down in Editable TextDocumentContentProvider for extensions #10547 (comment) and Unify our various places where resources are being saved #29025
• support file events from the remote source being reflected in the editor, e.g. update explorer, close editors, invalidate search caches etc.
• allow to search for files by their name in the same way we do it today using Cmd+P
• allow to search inside files, again merging with the existing search experience.
• think about language services/servers which today usually rely on having disk-access to files

The goal is to enable remote development via extensions, so new provider APIs are required to allow 3rd parties to integrate into more pieces of our system. Similar to #29025 we start with assessing how many assumptions are backed into our system and how we can make it aware of having multiple sources of truth, e.g. multiple search result providers, etc, etc.

[felixfbecker]

For language servers, this would require new ways for the language server to get text documents over LSP from the client instead from the disk - what do you think about https://github.com/sourcegraph/language-server-protocol/blob/master/extension-files.md?

[Chillee]

Is this going to be similar to Nuclide's remote dev support?

https://nuclide.io/docs/features/remote/

[codeflows]

Re: #10547

I also have a use case for editable/saveable TextDocumentProviders, or similar functionality by some other means. I've written a plugin that decrypts data to a virtual document. This is useful by itself, but it would be nice to allow editing the plain text file and encrypting it back upon save. I could probably implement this by decrypting to a temporary file instead and letting the user edit that, but having the functionality in TextDocumentProvider would make my implementation cleaner for sure.

[jrieken]

FYI - For August we will explore to hook into our search infrastructure. That means support for searching for and in files. Work has started here: #32549. Everyone please join the discussion.