Editing a file over scp fails on Windows

[thirstyice]

Problem

Attempting to edit a file using scp fails because the wrong path is provided for the local temp file.

Nvim tries to execute: scp -q "user@remote:/path/to/file" "/C/Users/User/AppData/Local/Temp/[...]"
which fails with "/C/Users/User/AppData/Local/Temp/[...]: No such file or directory
because "/C/Users[...]" is equivalent to "C:/C/Users[...]", and there is no C/ folder in the C: drive.

The path to the local file should be either "/Users/User/[...]" or "C:/Users/User/[...]"

Steps to reproduce

On Windows:

nvim --clean
:e scp://user@host//path/to/file

Expected behavior

Nvim tries to execute scp -q "user@remote:/path/to/file" "C:/Users/User/AppData/Local/Temp/[...]" and then proceeds as normal

Neovim version (nvim -v)

0.9.5, 0.10.0

Vim (not Nvim) behaves the same?

yes, 9.1

Operating system/version

Windows 11 23H2

Terminal name/version

cmd.exe, nvy.exe

$TERM environment variable

undefined

Installation

msi

[e-dong]

Regular vim on git-bash works because uses something like "/tmp/vUixOG6/0.lua".
/tmp corresponds to C:\Users\User\AppData\Local\Temp\3\

command:
scp -q 'user@remote:/path/to/file' '/tmp/v02boAV/0.lua'

vim git-bash version
VIM - Vi IMproved 9.1 (2024 Jan 02, compiled May 31 2024 15:14:09)

[justinmk]

We don't support netrw. The path forward for this is #21635

[e-dong]

It would be good to make nvim scp or :e scp throw an unsupported error or something like that.

[thirstyice]

We don't support netrw. The path forward for this is #21635

Given that #21635 is explicitly about auto-installing nvim remotely and using the client/server capabilities of nvim, while scp copies the remote file locally and does all the editing locally, I'd say that, for me at least, these are 2 different use cases entirely.
I don't want to install a copy of nvim remotely. I want to copy the file to my local machine, edit it, and send it back. Netrw allows me to do just that.
Given that netrw is documented in the official help files, is (largely) perfectly functional, and is not marked as deprecated for nvim in any place a normal user like myself would notice, declaring it unsupported in favour of a feature that doesn't exist yet and actually does something else entirely seems a bit premature to me.
However, if is the case that netrw is no longer supported, I would like to migrate my workflow to the replacement sooner rather than later.
What is the interim solution for editing a file off a remote server, while #21635 is still under development?

[clason]

declaring it unsupported

It means we do not support it, because it is maintained upstream (originally Dr. Chip; now vim/vim). We just vendor the files unchanged, same as the other Vim files in our runtime.

Since

Vim (not Nvim) behaves the same?

yes, 9.1

you should report this issue upstream.

[thirstyice]

Ah, I misunderstood the comment that nvim doesn't support it as meaning that nvim as an application doesn't support it, rather than just meaning that the nvim team is not responsible for it.

Thanks for the clarification!

[justinmk]

Given that netrw ... is not marked as deprecated

It will be eventually. But also, what @clason said is correct.

What is the interim solution for editing a file off a remote server

AFAIK, sshfs or similar is the most tractable. We may also consider something like distant as it matures (and that is mentioned in #21635).