Add Open File (SSH) and Open Folder (SSH)

[ghost]

Or to keep the gear menu clean, group them under the SSH menu.

The accepted input is of the form ssh://[USER@]HOST[:PORT]/PATH. If there is no ssh client available, warns the user and aborts.

The feature is very simple. It uses plain old scp instead of sshfs. I find sshfs unreliable and not always available. The process is straightforward: it copies the remote file or directory via scp into a temporary location (either the OS-defined temp directory or a user‑configured custom location). The user can also configure whether ecode should keep the file or directory or delete it upon closing. Finally, the file or directory is copied back to the remote using scp when closing.

We can add an extension to the Open File (SSH) and Open Folder (SSH) dialogs: Use rsync. I suggest allowing the user to configure whether ecode should keep the file or directory or delete it upon closing is because of rsync.

You can add a Use sshfs option, but make the checkbox disabled to indicate that it is not yet implemented.

[SpartanJ]

This could only exist as a plugin given that relies on external applications to provide a solution. But I really dislike the solution the way it's proposed, this needs to be implemented properly as remote-ssh like in other editors. ecode should have openssh embedded and handle this in a virtual file system. Copying files to the local file system is simply bad UX.

[ghost]

@SpartanJ Isn't @NullPlane's FR basically the same as mine?

#177

The only difference is that I described the feature in detail, whereas their FR only talks about it vaguely.

You closed my thread, so you should close theirs too!

[SpartanJ]

It's similar but it's not the same!
He's asking essentially for a plugin to manage files transfers over ssh via a GUI (essentially a graphical SFTP client). I did not close it because it would be nice, I won't do it myself any time soon.

[ghost]

OK, I got it. They are asking you to clone WinSCP/FileZilla.

[ghost]

@SpartanJ I still can’t think of why my method is bad. Vim does the same thing—it even invented the scp:// URL scheme for this purpose. Yes, I know the performance of scp for large directories is poor. However, this can be mitigated by making use of a compressed tarball. We will scp the tarball instead of the directory directly.

[ghost]

The Build and Run feature still has to utilize ssh to run on the remote machine. Most of the time, the language server will also need to run on the remote machine. These are harder issues.

[SpartanJ]

This can be done with plain ssh without using sshfs

OFC, I know. sshfs is just an abstraction over SFTP, which is an extension of the SSH protocol. But it's a very convenient abstraction since it behaves like any other file system, clients might not even know they're interacting in a sshfs mount, it just works.

Believe it or not, if you change the sync method from sshfs to either rsync or scp in your FreeBSD actions for ecode nightly, the build process will speed up significantly.

I might try it later, last time I checked there were some bugs there.

[SpartanJ]

Perhaps my scheme of just doing two-way scp or rsync once is too simplified and not practical. However, scp or rsync back and forth between local and remote is always possible. You can think of what we’ve copied or synced from the remote machine as simply a kind of cache to speed up local access.

Very very impractical. I've been there.

The Build and Run feature still has to utilize ssh to run on the remote machine. Most of the time, the language server will also need to run on the remote machine. These are harder issues.

If and only if that's something that it's wanted to be supported. Not really something I would support from the beginning for sure. I don't do any remote development so this probably won't be implemented by me any time soon.

[ghost]

I don’t do any remote development either. The method I’m talking about is purely imaginary. I once had the idea of running the language server on the remote machine, but it never worked out. Currently, I only edit random remote files occasionally. For this, I use ssh with the remote instance of nano/vim/emacs. I might submit more issues with the built-in terminal emulator in the future.

[SpartanJ]

Then we shouldn't waste time in features the users of ecode don't need. Specially if they are very complex like this one.