search

bodil / vscode-file-browser

https://marketplace.visualstudio.com/items?itemName=bodil.file-browser
GNU Lesser General Public License v3.0
86 stars 22 forks source link

VSCode Remote Support #6

Closed stevenguh closed 4 years ago

stevenguh commented 4 years ago

I am opening this issue to track the work to support VSCode Remote Support. Currently, there is no special handling for VSCode Remote, which means that this extension is a "workspace" extension, and required installation on remote to work. AFAIK, this extension use vscode API for file access and modification, so that makes it easier to support VSCode Remote, and allows this extension to run locally on the host.

  1. Fix the bug where open file browser doesn't work when opening a local file with a VSCode Remote instance. (This should be fixed by the 2.)
  2. Needs to pass the Uri to FileItem instead of just the fs path because Uri contains information if the file/workspace is a remote or not as well as to reconstruct the right Uri.
  3. Path separator is tricky because Path.sep is not reliable for when a user is on Window machine and ssh'ed into a linux box with the extension running locally
  4. Test environment like opening local file and file in network drive (like //drive/abc.txt) on a Windows host using vscode remote while the extension is running locally
  5. Needs to add extensionKind to the package.json to specify that this extension can be run locally. For example: ["ui", "workspace"] which prefers this extension to run locally and then remote.

I worked in this area before on the tab completion on vscode vim, it can be tricky. I can take a poke at this issue one on my free time. Let me know if you have any thoughts on this.

Note that this issue isn't asking for a "open local" file button like the built-in file dialog for remote, instead is to fix 1.

bodil commented 4 years ago

I think this should all be working now, but I'd appreciate a second opinion.

stevenguh commented 4 years ago

That's awesome!! Thank you for working on this. This works great for the most part. There are just some edge cases that are annoying to fix due to the api.

  1. I assume due to the usage of fsPath, the path separator is incorrect for when I remoting into different platform (e.g. Mac -> Windows, Windows -> Linux)
  2. Mac Remoting into Windows will display /c:/Path/To/ and can navigate all the way to the /

I did with something similar just last week and had to reimplement how vscode handle fsPath in the extension in order to copy path with the right separator. See https://github.com/VSpaceCode/VSpaceCode/blob/master/src/pathCommands.ts

Other than those in generally, it works great for drive path, and UNC path on locally windows that it doesn't navigate up correctly at C:\ and \\share\Folder\👍

bodil commented 4 years ago

Yeah, if you're running it locally it will display remote paths as if they were local paths, that's why I went with ["workspace", "ui"] instead of the opposite, so it should prefer the remote installation which will display the paths correctly if one exists. It would be consistent if I used Uri.path instead of Uri.fsPath, but then Windows users would be rather confused by the /C:/Users/etc instead of what they were expecting to see. So, tradeoffs all round, unfortunately.