Making TRAMP faster

Tramp is tolerable, but it is absolutely not great. You went on to demonstrate that right after making that claim, where you manually (and insufficiently) hack around its issues to arrive at something that is only barely comparable to eg what vs code can do.

Forgive my ignorance, but what does VSCode do?

Download a copy of itself onto the remote, run it there, and allow interaction with that copy

Editing a remote file is very common. Wanting to download and run a remote server every time you edit a remote file is far less common.

E.g. editing a config on an embedded device such as a router, editing a file inside a docker container, editing a file on a headless server, etc etc.

The only reasonable use case I can see for the vscode approach is if you're SSHing into your main development machine from another machine.

The remote server requirements include

> 1 GB RAM is required for remote hosts, but at least 2 GB RAM and a 2-core CPU is recommended.

That's pretty far from the SSH+vi use case that TRAMP replaces.

Correct. I didn't say it was a good thing :)

FWIW it is a one-time download on the remote, but still feels yucky, esp. for resource constrained settings (Pi like you mentioned, but also quota-limited containers etc.)

> Correct. I didn't say it was a good thing :)

Fair enough :)

Emacs can run as a server, and you can connect multiple local clients to it. I've tried various ways to have an emacs client connect to a remote emacs server (forwarding a socket over ssh, etc.) but never gotten it to work so there must be more to it than just the socket.

No, emacs in server-mode does not do what you'd expect. It is only useful to accelerate local start-up. Nothing to do with remote operations.

To be fair, for some dev workflows, TRAMP is lacking (LSPs), but it's more than enough if you're fine with grepping and ctags, I think. For the former scenario, I either run terminal emacs or use distrobox/toolbox (they setup everything for the wayland socket that graphical emacs needs)

I think it doesn't work over tcp but try with the other GUI library.

LSPs should work fine with TRAMP. In practice I have a problem with it, since there is some bad interaction between eglot, TRAMP, and clangd in certain cases, but that is a specific situation and a bug.

gopls was a bit of a pain. By default it uses stdio, and there were some integration issues with eglot, tramp, amd gopls. I also had some issues trying to use tcp ports. I switched to terminal emacs over ssh, the. use distrobox (I didn’t want to install dev tools locally).

The typical web dev won't care though, and go ahead downloading and installing a telemetry encumbered server onto the remote machine. All they need is the justification: "But it works!"

DevOps can tell them no all day long, they'll think they know better and give in to convenience over security every time.

What one could do is to block the download of VS Code on all infrastructure.

But it does run in terminal mode - I used to ssh into a remote machine and just run emacs in a terminal there. Actually, there was also some `screen' in the mix, but you get the idea. I preferred that over TRAMP because of the speed.

No I don't get the idea. I was disabusing people of the widely believed myth that an emacs server instance could host remote connections. That one can ssh into a remote machine and run emacs in tty mode is manifestly obvious.

To you, certainly, but perhaps not to everyone. And it can be a good third option in addition to TRAMP or "what vs code does".