I use tramp all day every b/c I mostly work on remote VMs so it is an indispensable tool. Note that tramp will allow you to go inside docker containers on those remote hosts with:

/ssh:<remote host>|docker:<docker container>

Also if you like copying (potentially large) files via dired, consider temporarily

(setq tramp-default-method "rsync")

The blog talks about rsync vs ssh a bit.

Also, using persistent ssh connections makes a huge difference, esp. if you’ve got a heavy shell init on the local or remote side

  Host *
      ControlPath ~/.ssh/cm-%r@%h:%p
      ControlMaster auto
      ControlPersist 600

I haven't been in a workflow where tramp is useful to me in a while. I recall it was borderline magical back when I did use it. I'm assuming it is highly reliant on how good your network connection is?

Definitely has more config now than I recall. Kudos on benchmarking the different settings here. I'm definitely curious to see what sort of stuff gets tried to make it even more seamless.

something i noticed while debugging tramp perf half the lag isn't tramp, it's elisp codepaths calling sync ops assuming they're cheap. i saw vc-git-root firing on every bufferlist switch because some mode wants to update a badge or refresh a modeline. none of it's aware that the path is remote

The async process sounds promising but unfortunately eglot doesn't work with it. I got a message from reddit that tramp 2.8.0-pre has fixed that issue but until last time I compiled HEAD from tramp repo it still doesn't work.

I just applied other configurations from the article and it seems faster than the default settings. Thank you author for sharing this!

https://www.gnu.org/software/tramp/#Overview For details about tramp, in case (like me) you had no idea what tramp is.

I kinda gave up on using it because so many of my remotes are tunneled through a jump host and I never could get it to connect seamlessly. It seems like it ought to, but when vscode just works with my ssh config, I decided debugging it was not a good use of my time. Might have something to do with being on a Mac, idk.

tramp is great. all the other mentioned solutions are nowhere near as seamless for “just do what i want, without distractions”.

vscode? “trust me bro, i will run a networked daemon on your server”. enjoy wondering which plugins to reinstall on your remote. enjoy installing proprietary shareware+telemetry plugins just to use git. try opening a local file and a remote file side by side in the same window. wifi connection broke for a sec? oops, you have to refresh the whole browser window.

want to edit a single file on a host you rarely connect to? enjoy spending 10 minutes setting up autosync solutions.

with any of the above - oops, you actually need sudo for that file in /etc? yeah, drop to shell and edit in vim.

there are other options to do stuff and for very specific predefined workflows they may win, but the versatility of tramp is still unmatched, especially if you do use emacs.

the only times ive had issues is when i have a weird shell setup on the remote - for that there is /sshx: instead of /ssh:

That's awesome. Thanks for sharing. I use tramp periodically and had to discover some of those on my own.

> I kept thinking to myself “There has to be a better way to do this”. I have started to think of ways to fundamentally improve the performance of TRAMP that would involve changes to the package itself. I plan to write more on that soon, so stay tuned!

Will look forward to it! TRAMP is really a gem and it does feel like it should be able to go faster. Either with some config tweaks to modernize it a bit, or some improvements in the caching or the sync logic.

TRAMP is neat, but I find watchexec+rsync to be a much more performant alternative. This way I keep editing files locally, and they're simply synced to the remote host when they change. This workflow also has the benefit of being able to use all my local tooling, it keeps a local copy which I often need, it supports any editor (forgive me, Father rms), and is easily configurable (include or exclude files, delete files on the remote, etc.).

So... people dont's save to local files and then manually ftp them anymore these days? I should check this stuff out

I have just launched a new website, https://www.threenh.com/. I also use this approach: TRAMP defaults to the ControlMaster=auto OpenSSH option, but it will override the ControlPath setting when starting an SSH session. TRAMP does this to avoid lag when the master session opened outside the Emacs session is no longer active. This is why TRAMP prompts for a password again even if an SSH connection has already been established.

I used to use TRAMP but now I just run terminal emacs through mosh. Everything just work and snappy, if you can live without the emacs GUI.

For those not into the lingo, Tramp is the Emacs module/package responsible for allowing you to transparently work on remote files and host in your local editor in a way I haven’t seen any other software do.

And yes, it’s really neat.

I use vim with mutagen for syncing files. It's simple and works fine, but you have to duplicate storage.

every few years, less often now, I see an article that gets me excited about tramp, and I try it and immediately deadlock my whole emacs because the remote shell had an unexpected character in the prompt or something.

Tramp is how I finally got over the chronic problem of having to use vim just for remote editing files on remote machines over an ssh session. It does sometimes hang and chug inconveniently, but dealing with that is far easier than delicately holding a config file like a flower while I remember the precise vim commands (and work around the TTY special code interpretation issues that break arrow keys) to make my edits to one line.

N'ah, forget that. It's worth the setup time to make Tramp go brr.

This is all good advice. TRAMP is really quite good once you figure out what's slowing it down.

I had a problem that was making it hang at times. Of course, Emacs would respond to `C-g` still, though. Toggling `toggle-debug-on-quit` showed me what was causing it to hang. Something from the ESS package which I rarely use anyway, so I just disabled it.

GNU's needs something like this too. It's glacial slow even with an SLRN cache.

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.

Nice and all, but what about the lessons we learned about running development as local as possible, eliminating the need for remote system access. all that sounds very 90's - 10s. These days you have a local environment that can emulate anything (see docker). Then you write code that interacts with that "anything" basically locally. When you are done with the code you can test and deploy - there is no need for remote access.

VMs should not be ssh'd into anymore - they should just be stamped over with the latest code drop. I mean did we not learn anything from the entire devops/ci/cd/immutability lessons of the last 10 years?

Tramp is an absolute garbage implementation (yeah, its author is just a terrible, sophomoric programmer) of the most naive mechanism you could imagine: bring the file over, edit it, copy it back. "celeritascelery" is genuinely better off using vim and git remotely, his hard-on for magit notwithstanding.

Making tramp go brr by removing half of features

Sad to see it's still so far from vscode. Is there really no way to make emacs magically work like vscode without modifying packages

Idk maybe invent something like jit-compilation but for remote/local code. Profile rtt latency then somehow dynamically calculate optimal local-remote code split and transfer remote part to remote machine