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.
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.
And then it also works with everything else that works with SSH.
N'ah, forget that. It's worth the setup time to make Tramp go brr.
> 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.
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.
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.
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 :)
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:
/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.
Host *
ControlPath ~/.ssh/cm-%r@%h:%p
ControlMaster auto
ControlPersist 600
Well behaved mode line items typically update a variable periodically so blocking never happens.
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.
josteink•4h ago
And yes, it’s really neat.
sylens•4h ago
jerf•3h ago
scbrg•3h ago
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•2h ago
scbrg•2h ago
Great post, by the way!
geocar•4h ago
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•3h ago
skydhash•3h ago
marai2•3h ago
skydhash•42m ago
klik99•2h ago
If anyones ever used the Plan 9 OS across network, TRAMP is like that for emacs
shadowgovt•4h ago
Editing as another user, editing a remote file, even editing over embedded protocols like adb: Tramp's got you covered.