4 ms·

TRAMP is neat, but I find watchexec+rsync to be a much more performant alternative. This way I keep editing files locally, and they're simply synced to the remo

by imiric 1y ago

TRAMP is neat, but I find watchexec+rsync to be a much more performant alternative. This way I keep editing files locally, and they're simply synced to the remote host when they change. This workflow also has the benefit of being able to use all my local tooling, it keeps a local copy which I often need, it supports any editor (forgive me, Father rms), and is easily configurable (include or exclude files, delete files on the remote, etc.).

wging 1y ago
I did the same thing when I was building on remote machines frequently. Either an internal one-way syncing tool or Unison, but basically the same as what I think you're implying. (Watchexec to notice changes, and kick off your local rsync to the remote machine, right?) 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?
- celeritascelery 1y ago
  > TRAMP rarely seemed worth it to fiddle with, especially when such a workflow supports all tools 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.
  - wging 1y ago
    That's exactly the point of remote syncing: whatever changes to code you make locally are nearly instantly available on a remote machine, so you can compile and run your software on a production-like machine. By "supports all tools" I mean that you can run whatever you like on your source code locally, whether it runs through emacs or not, and the result is available remotely. And with bidirectional syncing the reverse is true too.
    - anyfoo 1y ago
      But I cannot use the remote clangd for LSP, for example.
  - imiric 1y ago
    Right, I suppose it depends on your use case. For most of mine, my local machine has all the tooling, and I simply want to sync the files to a remote machine for deployment. But if you want to do all development remotely, then TRAMP might be the way to go.
- chriswarbo 1y ago
  > such a workflow supports all tools 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 :)
klik99 1y ago
Nice, I unfortunately need to work on Windows while also doing a lot of remote editing, so switched to emacs on wsl just to use tramp - I wasn't aware of watchexec which seems like a much better solution. However part of what makes tramp great is being able to use emacs just like it's local, so things like ag/magit/etc wouldn't work as smoothly.
dima55 1y ago
But then you can't do other stuff. Remote LSP, gdb, etc, etc.
- kleiba 1y ago
  What the OP presumably means is that they just have a local copy of all the files. Then you only edit local (with LSP, gdb, etc.) and any change you make to a local file is mirrored back to the remote copy automagically.
  - ParetoOptimal 1y ago
    This won't work for things that use a docker container without wrapper scripts, but those have their own problems.
  - anyfoo 1y ago
    Which means you can’t remote LSP, gdb, etc. 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.
apitman 1y ago
watchexec looks like exactly what I was looking for recently. Thanks for this.
pabs3 1y ago
lsyncd could be another alternative to that: https://github.com/axkibe/lsyncd https://github.com/axkibe/lsyncd

by imiric 1y ago

wging 1y ago

I did the same thing when I was building on remote machines frequently. Either an internal one-way syncing tool or Unison, but basically the same as what I think you're implying. (Watchexec to notice changes, and kick off your local rsync to the remote machine, right?) 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?

celeritascelery 1y ago
> TRAMP rarely seemed worth it to fiddle with, especially when such a workflow supports all tools 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.
- wging 1y ago
  That's exactly the point of remote syncing: whatever changes to code you make locally are nearly instantly available on a remote machine, so you can compile and run your software on a production-like machine. By "supports all tools" I mean that you can run whatever you like on your source code locally, whether it runs through emacs or not, and the result is available remotely. And with bidirectional syncing the reverse is true too.
  - anyfoo 1y ago
    But I cannot use the remote clangd for LSP, for example.
- imiric 1y ago
  Right, I suppose it depends on your use case. For most of mine, my local machine has all the tooling, and I simply want to sync the files to a remote machine for deployment. But if you want to do all development remotely, then TRAMP might be the way to go.
chriswarbo 1y ago
> such a workflow supports all tools 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 :)

klik99 1y ago

Nice, I unfortunately need to work on Windows while also doing a lot of remote editing, so switched to emacs on wsl just to use tramp - I wasn't aware of watchexec which seems like a much better solution. However part of what makes tramp great is being able to use emacs just like it's local, so things like ag/magit/etc wouldn't work as smoothly.

dima55 1y ago

But then you can't do other stuff. Remote LSP, gdb, etc, etc.

kleiba 1y ago
What the OP presumably means is that they just have a local copy of all the files. Then you only edit local (with LSP, gdb, etc.) and any change you make to a local file is mirrored back to the remote copy automagically.
- ParetoOptimal 1y ago
  This won't work for things that use a docker container without wrapper scripts, but those have their own problems.
- anyfoo 1y ago
  Which means you can’t remote LSP, gdb, etc. 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.

apitman 1y ago

watchexec looks like exactly what I was looking for recently. Thanks for this.

pabs3 1y ago

lsyncd could be another alternative to that: https://github.com/axkibe/lsyncd https://github.com/axkibe/lsyncd