[HN Gopher] Making TRAMP go Brrrr
___________________________________________________________________
Making TRAMP go Brrrr
Author : celeritascelery
Score : 151 points
Date : 2025-06-23 14:46 UTC (8 hours ago)
(HTM) web link (coredumped.dev)
(TXT) w3m dump (coredumped.dev)
| josteink wrote:
| 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.
| sylens wrote:
| Thank you. I don't know why more posts like this don't spend a
| line or two providing that context
| jerf wrote:
| Because the author had no particular expectation this would
| be a #1 hit on HN.
| scbrg wrote:
| 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 wrote:
| 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 wrote:
| Ah! That explains my confusion. Thanks for clarifying,
| and my apologies to sylens.
|
| Great post, by the way!
| geocar wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| marai2 wrote:
| 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 wrote:
| 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`.
| klik99 wrote:
| 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
| shadowgovt wrote:
| 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.
| globular-toast wrote:
| 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.
| kadico wrote:
| What a confusing headline. Sounded like he was about to describe
| homeless people and how to freeze them.
| rectang wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| shadowgovt wrote:
| LOL, lowest common denominator notch-lowerer goes brrr.
| chuckadams wrote:
| lol u mad bro?
| throitallaway wrote:
| 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 wrote:
| This is the way.
| PantaloonFlames wrote:
| Do you even emacs
| jonnycomputer wrote:
| 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.
| gray_-_wolf wrote:
| I found https://www.gnu.org/software/tramp/tramp-
| emacs.html#Multi_00... to be working pretty well, but it
| definitely took some fiddling and experimentation to get the
| right settings.
| jonnycomputer wrote:
| Thanks.
|
| Someday I'll get to fiddling with it again.
| aidenn0 wrote:
| 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.
| jerf wrote:
| 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.
| shadowgovt wrote:
| 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.
| rdtsc wrote:
| 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 wrote:
| Yeah. Thanks for writing all that up. I use TRAMP heavily, and
| any performance improvements would be welcome.
| taeric wrote:
| 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.
| SoftTalker wrote:
| 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.
| thom wrote:
| 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 wrote:
| 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 wrote:
| It recently gained native support for nspawn containers too
| (that used to require a third-party package)
| Twirrim wrote:
| https://www.gnu.org/software/tramp/#Overview For details about
| tramp, in case (like me) you had no idea what tramp is.
| imiric wrote:
| 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.).
| wging wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| anyfoo wrote:
| But I cannot use the remote clangd for LSP, for example.
| chriswarbo wrote:
| > 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 :)
| klik99 wrote:
| 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.
| dima55 wrote:
| But then you can't do other stuff. Remote LSP, gdb, etc, etc.
| kleiba wrote:
| 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 wrote:
| This won't work for things that use a docker container
| without wrapper scripts, but those have their own problems.
| anyfoo wrote:
| Which means you can't remote LSP, gdb, etc.
|
| In other words, it only works if your local platform is the
| same (or compatible) with the remote platform, or (in a
| limited capacity) if you have a viable cross compiling
| environment.
| apitman wrote:
| watchexec looks like exactly what I was looking for recently.
| Thanks for this.
| IceDane wrote:
| 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 wrote:
| Forgive my ignorance, but what _does_ VSCode do?
| kristjansson wrote:
| Download a copy of itself onto the remote, run it there, and
| allow interaction with that copy
| ants_everywhere wrote:
| 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 wrote:
| 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 wrote:
| > Correct. I didn't say it was a good thing :)
|
| Fair enough :)
| SoftTalker wrote:
| 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 wrote:
| 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 wrote:
| I think it doesn't work over tcp but try with the other
| GUI library.
| skydhash wrote:
| 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)
| anyfoo wrote:
| 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.
| skydhash wrote:
| 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).
| shwouchk wrote:
| 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 wrote:
| What about mounting a remote file system over sftp? Install
| EMACS or whatever editor you prefer on the remote?
| chriswarbo wrote:
| > 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.
| afr0ck wrote:
| I use vim with mutagen for syncing files. It's simple and works
| fine, but you have to duplicate storage.
| julienchastang wrote:
| 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.
| manoweb wrote:
| So... people dont's save to local files and then manually ftp
| them anymore these days? I should check this stuff out
| kristjansson wrote:
| 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 wrote:
| Isn't recent Tramp versions using this by default?
| bqmjjx0kac wrote:
| I thought TRAMP overrides that setting in your SSH config.
|
| > TRAMP uses the ControlMaster=auto OpenSSH option by default,
| if possible. However, it overwrites ControlPath settings when
| initiating ssh sessions. TRAMP does this to fend off a stall if
| a master session opened outside the Emacs session is no longer
| open. That is why TRAMP prompts for the password again even if
| there is an ssh already open.
|
| https://www.gnu.org/software/emacs/manual/html_node/tramp/Ss...
| lacrosse_tannin wrote:
| 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.
| anthk wrote:
| GNU's needs something like this too. It's glacial slow even with
| an SLRN cache.
| b0a04gl wrote:
| 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 wrote:
| 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 wrote:
| 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.
| nurumaik wrote:
| 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 wrote:
| 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.
| derekzhouzhen wrote:
| 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.
| sexyman48 wrote:
| 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.
| anyfoo wrote:
| TRAMPs goal is to be able to use ssh, scp, sftp, rsync etc.,
| without any special TRAMP support on the remote side.
| sunng wrote:
| 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!
| almosthere wrote:
| 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?
| anyfoo wrote:
| If you're a web developer, sure.
| PantaloonFlames wrote:
| What if my desktop is in the cloud ?
___________________________________________________________________
(page generated 2025-06-23 23:00 UTC)