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.
vscode is king here, even jetbrains feels crap compare to it.
Best solution is emacs on the remote server and get used to the 20ms which doesn’t sound bad IMO, but maybe you have less tolerance than me ;)
There’s no current solution in emacs for what you want and there could never be so I wouldn’t wait for it.
What do you mean by “stabilise things more”? I’m not sure that my experience is bad because of errors, so I’m probably misunderstanding what you’re saying.
I think the core issue is that software like magit simply wasn’t designed for high latency. If my remote machine was ~0ms away, I think things would work very well with tramp. It seems to me like this is the core problem, and anything that doesn’t address it won’t fix it. VSCode fixes the issue by letting software like magit simply run on the remote machine. It seems like the choice is between that, or rewriting everything to deal with high latency.
Have you tried just mounting the remote folder with
sshfs? Then you can just access it as a regular file, not just with emacs, with anything.I’ve been using tramp for remote C++ development for a little over 2 years now and was disappointed with the performance. Especially when it came to things like `git` operations, but general file system operations were noticeably slow.
I’ve not settled on using a OSC 52 supported terminal + tmux + emacs daemon/emacsclient directly on my remote machine. There were only a few keybinds I needed to work around (such as
C-S-/andC-Backspace). My tmux prefix key isC-twhich I never used in emacs anyway. The OSC 52 allows me to copy my emacs or tmux selections into my system clipboard so I’m happy about that. I still use GUI emacs locally for things like org and note taking.Overall very happy with this setup!
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.