3 ms·
> 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 (
by 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 agoThat'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 agoBut I cannot use the remote clangd for LSP, for example.
- imiric 1y agoRight, 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.