I’m interested to know what the future of remove development with emacs might look like. I’m a long time emacs user, and use rust, lsp-mode, magit and projectile heavily. The remote experience with tramp just isn’t very good. I’ve had to work around several bugs that lead to hangs, and even though I’m only ~20millis away from my remote machine performance is pretty bad. I believe I’ve already done everything I can to make it fast (ssh control master, etc.), and I’m still not happy. On the other hand, VSCode (which I’m not familiar with) or IntelliJ make remote development a breeze. I really like how they hide latency, and handle reconnects well. I’ve also tried terminal emacs on the remote machine, but I just can’t deal with the input lag.
It’s remarkable how emacs has been able to adapt over the years, and so I’m interested to hear about some ideas to keep emacs relevant for this usecase.
The future of remote development looks bright, thanks to advances in technology and remote-friendly regulations. However, balancing remote and in-person communication will continue to be critical to success.
If you use Magit, LSP and Projectile to code Rust, have you tried to clone the repo(s) you are working on to your local computer and enable git server on remote so you can push your changes. Or if you don’t wish to enable git server, transfer files from the work machine to remote via some other means (sftp) and just commit when you know you are done. It would remove the latency for the most part. Otherwise you are perhaps better off running Emacs on the remote and forward X to your work station, have you tried? Or probably even faster, just ssh into remote and run Emacs in terminal.
I am not sure if it is tramp problem; it is probably that you are just generating too much traffic if you are using Emacs on a remote as if you would be using it on your workstation.
My current solution: emacs server on remote machine and x2go server. Then remote to it with x2go client, single application mode. I do the same with intellij. Very happy with it. x2go is the best, you have your remote app seamlessly integrated with your host pc. If the connection is lost, just start over again your x2go client, your app still runs in remote host.
Previously I did ssh x forwarding, but I had to compile emacs with lucid toolkit because there is a bug with gtk toolkit which may crash emacs on connection lost.
xpra is an alternative to x2go but it is not as good.
Or if you have time, try lsp-bridge https://github.com/manateelazycat/lsp-bridge, it is truly the fastest lsp client for emacs. It also provides remote development feature similar to vscode. I’d love to hear others’ opinions if they’ve tried it.
I mount my development directory over sshfs, and have my own custom hacked up file-handler installed. It dispatches to OS filesystem calls for editing files, but ssh (through ssh+control master) for executing commands.
Eglot seems to work kind of ok. The remote LSP servers seem to die a lot and eglot tends to have difficulty restarting them, but I’m not convinced that’s related to the LSP servers being remote.
I had to disable the emacs VC integration for performance reasons, and I ended up just using git via the command line.
My setup is all quite hacky and I don’t like it, and I’d love a better solution. :)
The tramp maintainer wasn’t really keen on innovating anymore so somebody needs to volunteer.
I feel like network filesystem + some remote commands/plugins handler would stabilise things more. Even with sshfs mode, remote command doesn’t work.
It really doesn’t make sense that it supports so many network filesystems and none of them support remote command/process. If I could mount network filesystem locally, I wouldn’t use tramp to begin with.
