Making TRAMP faster

Original Article ↗ Hacker News Discussion ↗

What TRAMP Is and Why People Like It

  • Emacs package for “transparent” remote access: edit files, run shells, and use tools on remote machines as if local.
  • Integrates with the whole Emacs ecosystem: bookmarks, dired, Magit, search (ag/grep), shells, sudo, containers, multi-hop SSH, etc.
  • Many describe it as “magical” when it works: same keybindings and workflows for local, SSH, sudo, containers, and even multi-hop setups.

Performance Problems and Debugging

  • TRAMP often feels slow or hangs, especially with complex shells, heavy .ssh/config, or multi-hop/jump hosts.
  • Some users sped it up by:
    • Disabling problematic packages (e.g. ESS, over-eager VC integrations, modeline widgets).
    • Using Emacs’ toggle-debug-on-quit to see what blocks.
    • Adjusting TRAMP options (e.g. connection sharing, async process settings).
  • Several note that a large part of the lag is other Elisp code running expensive sync operations on remote paths (VC, modeline, etc.) without caching.

SSH, Multi-hop, and Connection Sharing

  • Multi-hop SSH works, but often “takes fiddling”: TRAMP syntax (/ssh:host|ssh:other|sudo:/...) or relying on ~/.ssh/config.
  • Some users report that turning off TRAMP’s own connection sharing and letting OpenSSH handle it made things “just work”.
  • There is discussion about TRAMP overriding ControlPath and how that can conflict with user-managed persistent SSH connections.

Alternatives and Competing Workflows

  • VS Code remote: praised as more reliable and faster, but criticized for needing a remote daemon, higher resource usage, and being overkill for simple edits or constrained devices.
  • Sync-based workflows (watchexec+rsync, lsyncd, mutagen, Unison):
    • Pro: editor-agnostic, leverage local tooling, simple mental model.
    • Con: don’t help with remote-only tools/LSPs, debugging, or complex multi-hop/sudo/container setups.
  • Other approaches: terminal Emacs over SSH/mosh, or running Emacs on the remote (sometimes via containers like distrobox/toolbox).

Criticisms and Limitations

  • Some say TRAMP is “tolerable but not great” or outright “garbage”, especially compared to VS Code’s remote model.
  • Pain points: hangs due to remote prompts, brittle against unusual shells, poor behavior on spotty connections, and limited LSP robustness in some setups.
  • Others counter that TRAMP’s low footprint, versatility (sudo, containers, embedded devices), and integration with existing Emacs workflows remain unmatched.

Broader Context

  • A few argue that modern CI/CD, containers, and immutable infrastructure should largely remove the need for interactive remote editing.
  • Others point out many workflows still require real remote access: embedded, heterogeneous platforms, “desktop in the cloud”, and resource-heavy or production-like environments.