ever 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.
kristjansson · 1m ago
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
imiric · 1h ago
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.).
dima55 · 54m ago
But then you can't do other stuff. Remote LSP, gdb, etc, etc.
klik99 · 54m ago
Nice, I unfortunately need to work on Windows while also doing a lot of remote editing, so switched to emacs on wsl just to use tramp - I wasn't aware of watchexec which seems like a much better solution. However part of what makes tramp great is being able to use emacs just like it's local, so things like ag/magit/etc wouldn't work as smoothly.
wging · 1h ago
I did the same thing when I was building on remote machines frequently. Either an internal one-way syncing tool or Unison, but basically the same as what I think you're implying. (Watchexec to notice changes, and kick off your local rsync to the remote machine, right?)
TRAMP rarely seemed worth it to fiddle with, especially when such a workflow supports all tools, even those run in a CLI outside of emacs: run a formatter or other automation locally and have the changes propagate? git pull locally, ditto? why not?
celeritascelery · 43m ago
> TRAMP rarely seemed worth it to fiddle with, especially when such a workflow supports all tools
The problem is that this workflow doesn't support all tools (or even most tools in my case). The remote machines are a different OS with more RAM and are set up with all the tools and production environments needed. I can't run most of the locally (at least not without massive effort and porting). If you have an environment where you can easily run locally or remotely, then your workflow would make sense.
manoweb · 11m ago
So... people dont's save to local files and then manually ftp them anymore these days? I should check this stuff out
julienchastang · 14m ago
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.
taeric · 1h ago
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.
thom · 1h ago
Just thought about this for a second and it made me sad: I haven't SSH'd into a machine in at least a couple of years at this point. Everything works through web frontends, git, CI/CD, Terraform etc. Actually editing a file on a server instead of treating everything as amorphous ephemeral compute would be a real guilty pleasure!
lotharcable · 1h ago
Tramp can work better for containers then it does over SSH.
I use it conjunction with distrobox and podman. It should be able to work with kubernetes as well.
SoftTalker · 1h ago
There's very little if any config that is strictly necessary. I used to use TRAMP quite a bit and I never configured anything. Of course like all emacs packages you can config and tweak it to your heart's content.
jonnycomputer · 2h ago
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.
jerf · 1h ago
I think that in general, if you're doing anything fancy with SSH, you're better off setting it up in SSH than trying to convince Tramp to do anything with it. See something like https://wiki.gentoo.org/wiki/SSH_jump_host . Basically, the goal is you should be able to type "ssh someSSHConfig" and get to the shell of the device. If you can do that, you don't need to worry about what Tramp can and can't do, and if SSH adds a feature that works in the SSH config you don't even have to wonder if Tramp can use it.
And then it also works with everything else that works with SSH.
I found that setting (customize-set-variable 'tramp-use-connection-share nil) made things "just work" with my .ssh config (the documentation for that variable seems to imply this is expected).
If you still want connection sharing, you'll have to set it in your .ssh config, but it works without it.
afr0ck · 22m ago
I use vim with mutagen for syncing files. It's simple and works fine, but you have to duplicate storage.
rdtsc · 1h ago
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.
dima55 · 44m ago
Yeah. Thanks for writing all that up. I use TRAMP heavily, and any performance improvements would be welcome.
shwouchk · 35m ago
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:
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.
kleiba · 53m ago
Forgive my ignorance, but what does VSCode do?
kristjansson · 6m ago
Download a copy of itself onto the remote, run it there, and allow interaction with that copy
shadowgovt · 2h ago
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.
globular-toast · 2h ago
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.
josteink · 2h ago
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.
geocar · 2h ago
> in a way I haven’t seen any other software do.
It was novel once upon a time, but almost every internetworked operating system supports network-transparent files. Even my iPhone can do it.
Linux is a bit weird though: VIM has netrw which is very similar to Emacs; Gnome has a special VFS API that understands URIs, but only in the loosest possible sense of the word, and it can't work with autofs to "un-URI" something into a regular unix path, which is just sad.
But if you don't care about that, autofs can make it possible to cd /net/{hostname} and get my home directory over ssh on another machine, and works much better than tramp IMO, even under Emacs.
gray_-_wolf · 1h ago
The thing is TRAMP also gives you a shell, not just a file access. When I am in a remote buffer, I can do M-x shell, and I will get a command line running on the remote host. What is more, since the T stands for Transparent, when I want to insert e.g. output of some command into a buffer, the command is executed on the remote host and I do not have to do anything special to achieve that, it just happens auto-magically based on the directory of current file (local vs. remote). I find that useful, and you cannot really do these things with a network drive on Windows.
skydhash · 1h ago
It's not only about transparent access. It's about how the whole emacs ecosystem working with the files. So you can bookmark a remote file, and once accessed, you can launch dired (the file manager) for the file's directory, run the shell on the remote,... with the same binding and mechanism you have for local files. No need to alter configuration or launch a special windows for the project.
klik99 · 46m ago
Exactly this, it's hard to explain to a non-emacs user why TRAMP is so magical, but the number of times I tried to run something that was meant to run locally on my machine through TRAMP and it just worked is very impressive. It runs so smoothly that you forget you're executing things on a remote machine, and when that leaks through it's typically very easy to diagnose and fix - for instance I have ag (silver searcher) installed on my local machine, tried running a search with ag via tramp and the bin obviously wasn't on the remote machine, a simple apt-get later and I could run my search with all my custom settings remotely.
If anyones ever used the Plan 9 OS across network, TRAMP is like that for emacs
marai2 · 59m ago
I’ve been using emacs for many years and I had no idea you can bookmark files let alone bookmark remote files! Thanks for educating me today!
sylens · 2h ago
Thank you. I don’t know why more posts like this don’t spend a line or two providing that context
scbrg · 1h ago
So, here's the first three sentences in the linked article:
I recently changed jobs and found myself in a position where I would need to do a lot of work on remote machines. Since I am Emacs user, the most common way to do this is using TRAMP (Transparent Remote access, Multiple Protcol). TRAMP is an Emacs package that let’s you treat a remote host like a local system, similar to VSCode Remote Development Extension.
Doesn't that provide context?
celeritascelery · 41m ago
To be fair, I added that after reading the parent comment. I did a poor job of describing what TRAMP was because I targeting this towards Emacs users.
scbrg · 38m ago
Ah! That explains my confusion. Thanks for clarifying, and my apologies to sylens.
Great post, by the way!
jerf · 1h ago
Because the author had no particular expectation this would be a #1 hit on HN.
shadowgovt · 1h ago
It is a very special piece of work. The closest I've seen is vscode remote editing (and credit where it's due: vscode remote editing is out of the box far more reliable and stable than Tramp... it better be, since it's running its own daemon on the remote machine), but Tramp is far more general-purpose than vscode's solution.
Editing as another user, editing a remote file, even editing over embedded protocols like adb: Tramp's got you covered.
kadico · 2h ago
What a confusing headline. Sounded like he was about to describe homeless people and how to freeze them.
rectang · 2h ago
Apparently it's a 2020 meme about "make the money printer go brr". I didn't know that one, so I assumed it was a reference to the A-10 Warthog's Gatling gun, which used to be stylized as "brrrt".
shadowgovt · 1h ago
I'm not nearly as deep a scholar of memes as some, but I wouldn't be surprised if the two are actually related; I believe they both originated from 4chan.
rectang · 1h ago
You're probably right. It was somewhat reassuring to learn of the money printer variant — to me, the Warthog "brrrt" meme evokes human flesh being torn apart (also tanks, but strafing runs often target ground troops, and there are of course people inside those tanks) and it was unsettling to think that this post might be comparing the performance of Tramp to the extremely violent destruction of your adversaries.
fumeux_fume · 2h ago
Brain rot ushered this idiotic meme a few years ago and I was happy to see it fade away. Seeing "go brrr" all over HN now is, if anything, an indicator of lowest common denominator moving another notch down.
chuckadams · 1h ago
lol u mad bro?
shadowgovt · 1h ago
LOL, lowest common denominator notch-lowerer goes brrr.
TRAMP rarely seemed worth it to fiddle with, especially when such a workflow supports all tools, even those run in a CLI outside of emacs: run a formatter or other automation locally and have the changes propagate? git pull locally, ditto? why not?
The problem is that this workflow doesn't support all tools (or even most tools in my case). The remote machines are a different OS with more RAM and are set up with all the tools and production environments needed. I can't run most of the locally (at least not without massive effort and porting). If you have an environment where you can easily run locally or remotely, then your workflow would make sense.
/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.
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.
I use it conjunction with distrobox and podman. It should be able to work with kubernetes as well.
And then it also works with everything else that works with SSH.
Someday I'll get to fiddling with it again.
If you still want connection sharing, you'll have to set it in your .ssh config, but it works without it.
> 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.
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:
N'ah, forget that. It's worth the setup time to make Tramp go brr.
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.
And yes, it’s really neat.
It was novel once upon a time, but almost every internetworked operating system supports network-transparent files. Even my iPhone can do it.
Linux is a bit weird though: VIM has netrw which is very similar to Emacs; Gnome has a special VFS API that understands URIs, but only in the loosest possible sense of the word, and it can't work with autofs to "un-URI" something into a regular unix path, which is just sad.
But if you don't care about that, autofs can make it possible to cd /net/{hostname} and get my home directory over ssh on another machine, and works much better than tramp IMO, even under Emacs.
If anyones ever used the Plan 9 OS across network, TRAMP is like that for emacs
I recently changed jobs and found myself in a position where I would need to do a lot of work on remote machines. Since I am Emacs user, the most common way to do this is using TRAMP (Transparent Remote access, Multiple Protcol). TRAMP is an Emacs package that let’s you treat a remote host like a local system, similar to VSCode Remote Development Extension.
Doesn't that provide context?
Great post, by the way!
Editing as another user, editing a remote file, even editing over embedded protocols like adb: Tramp's got you covered.