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 · 3h ago
But then you can't do other stuff. Remote LSP, gdb, etc, etc.
kleiba · 1h ago
What the OP presumably means is that they just have a local copy of all the files. Then you only edit local (with LSP, gdb, etc.) and any change you make to a local file is mirrored back to the remote copy automagically.
ParetoOptimal · 1h ago
This won't work for things that use a docker container without wrapper scripts, but those have their own problems.
klik99 · 3h 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 · 4h 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?
chriswarbo · 17m ago
> such a workflow supports all tools
Well, it doesn't support anything that we want to actually run on the remote. TRAMP isn't just about files: M-! in a TRAMP buffer will execute the command on the remote; M-x shell will start a shell-mode session that's running on the remote; and so on.
Also, TRAMP remotes don't need to be other machines; e.g. the `sudo` remote lets us open local files with sudo permissions. It's nice to use the same mostly-transparent approach to access other machines, other users, containers, etc.
Also, multi-hop remotes would be more painful to manage without TRAMP, e.g. Emacs will open a path like `/ssh:bastion|ssh:other-machine|sudo:/etc/foo` will open an SSH connection to `bastion`, and from there will open an SSH connection to `other-machine`, and on there will open the file `/etc/foo` using sudo privileges. Again, all the TRAMP goodies like M-! will work as they normally do :)
celeritascelery · 3h 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.
wging · 1h ago
That's exactly the point of remote syncing: whatever changes to code you make locally are nearly instantly available on a remote machine, so you can compile and run your software on a production-like machine. By "supports all tools" I mean that you can run whatever you like on your source code locally, whether it runs through emacs or not, and the result is available remotely. And with bidirectional syncing the reverse is true too.
apitman · 1h ago
watchexec looks like exactly what I was looking for recently. Thanks for this.
julienchastang · 2h 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.
kristjansson · 2h 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
sunng · 2h ago
Isn't recent Tramp versions using this by default?
taeric · 4h 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 · 4h 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 · 3h 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.
chriswarbo · 15m ago
It recently gained native support for nspawn containers too (that used to require a third-party package)
SoftTalker · 4h 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.
b0a04gl · 2h ago
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
celeritascelery · 1h ago
That's exactly it. TRAMP itself works fine, but some packages that are only tested on local machines use a bunch of shell calls that are not really needed (i.e. They could cache the result).
ParetoOptimal · 1h ago
A lot of times with emacs you can disable the modeline and get performance improvements because frequent updates happen and arent cached.
Well behaved mode line items typically update a variable periodically so blocking never happens.
sunng · 41m ago
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!
jonnycomputer · 4h 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 · 4h 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.
shwouchk · 3h 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:
graemep · 54m ago
What about mounting a remote file system over sftp? Install EMACS or whatever editor you prefer on the remote?
chriswarbo · 3m ago
> What about mounting a remote file system over sftp?
That can be OK for some tasks, but not others. For example, TRAMP will execute commands on the remote; so commands like M-x find-grep-dired will be faster when using TRAMP.
> Install EMACS or whatever editor you prefer on the remote?
There's actually a lot of flexibility there, since Emacs is perfectly usable in a text terminal, which could be run over SSH; it can also show X11 windows over the network (though I recommend the "lucid" build, rather than GTK); and it also has a client/server mode.
almosthere · 38m ago
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?
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.
rdtsc · 4h 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 · 3h ago
Yeah. Thanks for writing all that up. I use TRAMP heavily, and any performance improvements would be welcome.
nurumaik · 1h ago
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
ParetoOptimal · 1h ago
There is inherent limitation of latency/responsiveness in the tramp model versus the copy vscode server to my server and communicate with it model.
The tramp model does have the advantage of little to no resource usage, but these days most aren't concerned about that.
manoweb · 2h ago
So... people dont's save to local files and then manually ftp them anymore these days? I should check this stuff out
afr0ck · 3h ago
I use vim with mutagen for syncing files. It's simple and works fine, but you have to duplicate storage.
lacrosse_tannin · 2h ago
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.
globular-toast · 5h 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.
IceDane · 3h ago
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 · 3h ago
Forgive my ignorance, but what does VSCode do?
kristjansson · 2h ago
Download a copy of itself onto the remote, run it there, and allow interaction with that copy
ants_everywhere · 2h ago
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.
kristjansson · 2h ago
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.)
ants_everywhere · 1h ago
> Correct. I didn't say it was a good thing :)
Fair enough :)
skydhash · 1h ago
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)
SoftTalker · 1h ago
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.
sexyman48 · 1h ago
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.
ParetoOptimal · 1h ago
I think it doesn't work over tcp but try with the other GUI library.
anthk · 2h ago
GNU's needs something like this too. It's glacial slow even with an SLRN cache.
shadowgovt · 4h 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.
josteink · 5h 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 · 4h 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 · 4h 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 · 4h 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 · 3h 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 · 3h 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!
skydhash · 1h ago
It's a neat feature. I typically bookmark directories on remote hosts, project roots, config files, etc,.. BTW, you can use `list-bookmarks` then annotate each bookmark with `e`, and display all the annotations with `A`.
sylens · 4h ago
Thank you. I don’t know why more posts like this don’t spend a line or two providing that context
scbrg · 3h 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 · 3h 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 · 3h ago
Ah! That explains my confusion. Thanks for clarifying, and my apologies to sylens.
Great post, by the way!
jerf · 4h ago
Because the author had no particular expectation this would be a #1 hit on HN.
shadowgovt · 4h 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 · 5h ago
What a confusing headline. Sounded like he was about to describe homeless people and how to freeze them.
rectang · 5h 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 · 4h 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 · 4h 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 · 4h 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 · 4h ago
lol u mad bro?
shadowgovt · 4h ago
LOL, lowest common denominator notch-lowerer goes brrr.
throitallaway · 2h ago
I always downvote this brain rot low effort crap. An article could be a dissertation containing the meaning of life itself, but if it's meme-laden I'm not reading it. I get so annoyed by oft-repeated phrases ("This is the way", "Take my upvote", "This.", "This guy Xes", "ngl") and "go brr" this is no exception.
ParetoOptimal · 1h ago
This is the way.
sexyman48 · 1h ago
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.
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?
Well, it doesn't support anything that we want to actually run on the remote. TRAMP isn't just about files: M-! in a TRAMP buffer will execute the command on the remote; M-x shell will start a shell-mode session that's running on the remote; and so on.
Also, TRAMP remotes don't need to be other machines; e.g. the `sudo` remote lets us open local files with sudo permissions. It's nice to use the same mostly-transparent approach to access other machines, other users, containers, etc.
Also, multi-hop remotes would be more painful to manage without TRAMP, e.g. Emacs will open a path like `/ssh:bastion|ssh:other-machine|sudo:/etc/foo` will open an SSH connection to `bastion`, and from there will open an SSH connection to `other-machine`, and on there will open the file `/etc/foo` using sudo privileges. Again, all the TRAMP goodies like M-! will work as they normally do :)
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.
Well behaved mode line items typically update a variable periodically so blocking never happens.
I just applied other configurations from the article and it seems faster than the default settings. Thank you author for sharing this!
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.
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 can be OK for some tasks, but not others. For example, TRAMP will execute commands on the remote; so commands like M-x find-grep-dired will be faster when using TRAMP.
> Install EMACS or whatever editor you prefer on the remote?
There's actually a lot of flexibility there, since Emacs is perfectly usable in a text terminal, which could be run over SSH; it can also show X11 windows over the network (though I recommend the "lucid" build, rather than GTK); and it also has a client/server mode.
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?
> 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.
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
The tramp model does have the advantage of little to no resource usage, but these days most aren't concerned about that.
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.
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.
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.)
Fair enough :)
N'ah, forget that. It's worth the setup time to make Tramp go brr.
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.