Emacs

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.

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.

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.

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?

I've been using Emacs w/ TRAMP for remote dev for 3 years. I use lsp-mode w/ clangd, eshell, magit. Because of my setup I can't build locally, both as the project won't build on macOS and because it'd probably take 45m-1hr to clean build versus a few minutes on the server.

I agree that the experience isn't flawless, despite using ControlMaster etc I still have latency on save/revert, and staging+committing in Magit too. The worst is getting the ssh sessions "crossed up", where lsp-mode is transferring some data or a grep job is running and I hit C-x C-f, and Emacs locks up, needing a healthy dose of C-g spam to get it back.

Despite all the problems, I still feel that Emacs is a better remote dev environment for me. I work on a large archaic project with an elaborate build system, multiple "in-house" languages, and Emacs works wayy better for weirdo projects like this than VS Code. The rest of my team, and the company as a whole, uses VS Code and I've seen coworkers have it drop out, lock up, and be clunkier than TRAMP in some situations. The amount of configuration to get it working well (especially clangd+lsp) isn't any easier than Emacs.

IMO all that Emacs needs to let it stand up against VS Code for remote dev is to improve the performance and polish (latency and lockups). The architecture is fundamentally the same as VSCode, especially if you're using lsp-mode or eglot. Emacs will never appeal to the "Out-of-the-box" users as VS Code does, but for the power users it should still be fast and work seamlessly.

I just ssh into the server and run emacs over ssh. X forwarding works well if the internet is good enough/close enough to the server. All other remote approaches have not worked well for me.

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.

He's talking concept and you're taking implemenation.

I almost exclusively use emacs --daemon and then emacsclient to connect to it.

In my opinion, this model needs to be extended so that emacs daemons can't accept connections over a network. Maybe piggybacking SSH, or some other socket protocol. Of course, never could administrators would have to enable that port, so there are complications in professional environments.

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.

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.

With VSCode it requires nodejs on the server side,

That's not true.

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.

Wrong. Vscode server is a binary blob, it only requires glibc. It doesn't need anything else, like shells. It even brings its own git.

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 -nw on 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.

I've submitted a request to have you banned. Look at your history. You contribute nothing and just spew annoying nonsense. Adios.

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.

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 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. :)

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.

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.

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-/ and C-Backspace). My tmux prefix key is C-t which 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!

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.