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.
I’ve submitted a request to have you banned. Look at your history. You contribute nothing and just spew annoying nonsense. Adios.
Is this functionality just used by people trying to use Windows and WSL as a development environment?
My previous employer did not allow non public source code on a laptop. My solution was to run emacs inside of a screen session (with screen’s C-a mapped to C-t a trick I learned from a colleague since C-t twiddle character isn’t very useful in emacs). This worked well even using terrible cellular wifi and was much better than remote desktop since the amount of data sent per keystroke will typically be quite small.
Without screen this almost works but emacs could hang sometimes when the connection got dropped which screen solves.
Sure it can. Why couldn’t it? At worse, you could write a multi-threaded C library and have emacs/emacsclient call into it.
Why not just run
emacs -nwon ssh? If latency is bad, use xterm(one of the lowest latency)I may have a few tweaks I can check tomorrow at my work machine, but mine was never that bad. I find the diff is slow and can freeze up for a minute or two if you run a huge multi thousand file diff, but I don’t imagine its that. Have you tried disabling magit-revert mode, or eglot mode? LSP or auto-revert checking the file state are usually culprits of lag for me.
Or did you install Emacs on the server you SSH’d into?
That one, I believe. Eliminating Tramp from the equation is an easy and effective way to avoid Tramp-based overheads!
Unless your network connection is very slow or otherwise issue-prone, in which case ssh may not be responsive – at which point Tramp offers significant advantages by only occasionally requiring network activity.
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.
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.
I think emacs should adopt vscode remote dev architecture: install a remote server and communicate with it using some rpc protocol. Maybe someone is working on it, I don’t know.
This discussion should happen on the emacs dev mailing list, if you want to involve the core developers.
When possible, I think it’s much better to edit the code locally and synchronize it periodically with the remote. This doesn’t need to be clunky, and is an extension of the fact that you need to periodically synchronize buffer contents with their file a.k.a. save them.
That’s why I said that model needs to be extended. There’s no reason emacs server couldn’t send stuff over a TCPsocket to emacs client. Emacsclient and emacs server are separate OS processes, so they already communicate via external mechanisms.
I also use terminal emacs in some cases, but there are a few key bindings which make the graphical version a bit better in some cases. But I mostly only do R/cpp remotely. I don’t know how it is for other languages.
If you run a remote LSP and connect to it from lsp-mode, can the file saves be sent through that? Or does thr LSP only do file checks and refactors and such, not offer raw file get/put?
On the server. You just ssh -X, and call emacs. You can also use emacsclient on the server and then (also on the server) connect to it with the graphical client. This helps when you want to prevent connection los to break your process running. Or emacs -nw also works. There are no special commands used.