4 ms·

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, s

by anyfoo 6y ago

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.

mcqueenjordan 6y ago
Really good call outs. Seamless toolchain integration with the remote host while on a TRAMP buffer has been a painpoint for me.
- taeric 6y ago
  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. :(
  - anyfoo 6y ago
    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.
smabie 6y ago
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.
- znpy 6y ago
  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).
  - contravariant 6y ago
    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).
    - znpy 6y ago
      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).
      - disgruntledphd2 6y ago
        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).
        deleted 6y ago
        [deleted]
  - dan-robertson 6y ago
    Tramp works for non-ssh remote terminals. Also it leads to remote commands running automatically rather than running commands locally against a remote fs.
- jlg23 6y ago
  TRAMP works well over slow connections and, if told to save temporary files locally, deals with connection loss pretty well.
- chriswarbo 6y ago
  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)
  - ProfDreamer 6y ago
    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_002dhoc-multi_002dhops.html https://www.gnu.org/software/emacs/manual/html_node/tramp/Ad...
    - kqr 6y ago
      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.

by anyfoo 6y ago

mcqueenjordan 6y ago

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

taeric 6y ago
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. :(
- anyfoo 6y ago
  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.

smabie 6y ago

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.

znpy 6y ago
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).
- contravariant 6y ago
  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).
  - znpy 6y ago
    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).
    - disgruntledphd2 6y ago
      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).
      - deleted 6y ago
        [deleted]
- dan-robertson 6y ago
  Tramp works for non-ssh remote terminals. Also it leads to remote commands running automatically rather than running commands locally against a remote fs.
jlg23 6y ago
TRAMP works well over slow connections and, if told to save temporary files locally, deals with connection loss pretty well.
chriswarbo 6y ago
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)
- ProfDreamer 6y ago
  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_002dhoc-multi_002dhops.html https://www.gnu.org/software/emacs/manual/html_node/tramp/Ad...
  - kqr 6y ago
    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.