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.).
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.
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.
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.
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?
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 :)
> 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.
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.
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.
