Hacker News Reader

Comment by anyfoo | Hacker News Reader

Some goodies in there. For example, a clear direction into making more things work when editing on remote hosts out of the box. I hope lsp/eglot pick that up, so that I can now edit on a remote host via ssh just like I could on a local one and still have semantic completion, references etc. Or the ability to just run ripgrep on the remote host transparently.

View on HN

Honest question: doesn't sshfs solve this problem? I've never understood the appeal of TRAMP, mounting the remote resources seems like a much better and less finicky solution.

You might not have the required host permission to mount a filesystem or you might not have sshfs at all (think about gnu emacs on windows).

Tramp is agnostic in most things (well, you need an ssh client at least).

Calling tramp a solution for windows is somewhat iffy though. So far I don't think there's an easy way to simply get it to work on windows (the path handling seems to forbid tramp-like paths on windows, which messes with things quite considerably).

Meh, it worked well enough for me when I had to use it on windows 7 first and 10 later (using putty as ssh client).

Yeah, you can get it to work with putty, but it's nowhere near as reliable as from Mac/Linux to server (and to be fair, network issues make it a less than optimal solution if you have a choice).

These days I just tmux on the server, open emacs and hack away (as long as you can install things on the server).

Tramp works for non-ssh remote terminals. Also it leads to remote commands running automatically rather than running commands locally against a remote fs.

TRAMP works well over slow connections and, if told to save temporary files locally, deals with connection loss pretty well.

There are some semantics differences, e.g. if a remote buffer is open then `shell-command` (M-!) will run commands on the remote machine and `shell` will open a terminal which is logged in to the remote machine. I run all my terminals in Emacs, so I use these a lot (my init.el wraps the latter in a function which invents new buffer names shell-1, shell-2, etc.).

TRAMP also feels faster to me; I presume it's due to background jobs adjusting their casual I/O usage when TRAMP is detected, like writing backup/lock files, scanning directories for VCS info, etc. which has high latency on SSHFS.

I also like using `/sudo:root@localhost:/foo` for editing local files with different user permissions (plus the same command and terminal behaviour as with SSH)

multi-hops[0] should probably be mentioned as well. Using those one can for example open a file using sudo via ssh:

    /ssh:you@remotehost|sudo:remotehost:/path

Doing any further actions on a file opened that way also applies the hops there as well. For the example above opening a shell or running a shell-command would run those through sudo on the remote host.

[0]: https://www.gnu.org/software/emacs/manual/html_node/tramp/Ad...

It's worth mentioning that this is not limited to SSH followed by sudo. It can also be used to edit remote files through a bastion host, by just adding more SSH hops to the file path.

Really good call outs. Seamless toolchain integration with the remote host while on a TRAMP buffer has been a painpoint for me.

What are the specific pain points? Is it a limitation of lsp? This is one of the things that has felt magical in Emacs for near the past decade for me. So much "just works" if local or remote.

Now... Now that I am on 4g internet... I admit things can feel slow wicket than I'd care for. :(

One painpoint for me was that no matter what I tried, I couldn't get eglot to connect to a remotely started clangd. I haven't checked if that's solved now, but good to see that there's some momentum in remote editing in general.

Reply on news.ycombinator.com