- http://blog.atom.io/2017/09/12/announcing-atom-ide.html
- http://blog.atom.io/2017/11/15/code-together-in-real-time-wi...
Still beta, though.
- http://blog.atom.io/2017/09/12/announcing-atom-ide.html
- http://blog.atom.io/2017/11/15/code-together-in-real-time-wi...
Still beta, though.
Remote editing is logging into a remote machine, and being able to manipulate the files there just as if they were stored locally. Nuclide gets this right https://nuclide.io/docs/features/remote/
Various sync plugins aren't reasonable because they want code in both places, which is a complete waste because you'll never run the local code. Alternatively, many of these require various per project config files which is just too much overhead.
The rmate-like plugins look interesting until you find out that there's no integration with the tree view, or any of the project like searching.
Some "solutions" that people point to are simply file transfer UIs, which is just misunderstanding the problem.
This thread really explains the problems with all of these approaches. https://discuss.atom.io/t/working-with-a-remote-server-throu... Sadly, only Nuclide does it right, but god is there a lot of shit with it.
I guess I'll have to go with sshfs, but that's also a bit awkward.
What's wrong with sshfs? That does it at the OS level and it then works for everything?
Also, you have to remember to mount and unmount the drive outside of the editor, (especially if you close your laptop for a while), whereas if the editor manages the connection, then it's transparent to your normal workflow.