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.
Host vm3
User myusername
HostName the-host-name
ProxyCommand ssh -W %h:%p myusername@jump.host.address
The thing that I had to fiddle with, was getting ssh and tramp to use the same ControlPath to share sockets because it helped make things smooth if you had setup ssh to use ssh-agent and persist connections already.
But yeah, I get why just giving up on tramp has been easier over the years. Besides connecting there's also annoyances on spotty internet that make avoiding it usually a better experience. I think I haven't relied much on tramp after trying to use it and realising tmux+emacs was overall better at the time, mainly because I could just hop on my workstation to the exact same session I was using once RTO happened. Nowadays I use it mostly for sudo and one off things, but not remote projects with remote compile and lsp anymore.
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.
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 :)
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.
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 :)
DevOps can tell them no all day long, they'll think they know better and give in to convenience over security every time.
What one could do is to block the download of VS Code on all infrastructure.
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.
as for sftp, unfortunately that’s not an option if you happen to use windows locally eg for work reasons, nor if you use a mac as of several years now, since fuse became closed source.
not to mention, again, the fact that you are limited to whatever root you decided to mount, limited to editing as a user that i’ve already mentioned, as well as limited from using remote tools as sibling stated. try making a git commit over sftp.
if you have a focused “working on a project” workflow it may work, otherwise PITA
most of my remote editing fits into your description. of course, if you’re not an emacs user, you likely won’t find much value in tramp, magit, org-mode, dired, ediff, eshell, etc
/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.
When moving large files.
> Do you know what the author means?
I am not sure, but I think you want ssh most of the time except when moving large files.
Host *
ControlPath ~/.ssh/cm-%r@%h:%p
ControlMaster auto
ControlPersist 600> 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/Ssh-setup.html
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.
For quick file transfer/check, it is faster with Tramp.
I just applied other configurations from the article and it seems faster than the default settings. Thank you author for sharing this!
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?
And yes, it’s really neat.
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!
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
Editing as another user, editing a remote file, even editing over embedded protocols like adb: Tramp's got you covered.