3 ms·

They are: - http://blog.atom.io/2017/09/12/announcing-atom-ide.html http://blog.atom.io/2017/09/12/announcing-atom-ide.html - http://blog.atom.io/2017/11/15/c

by dflock 9y ago

They are: - http://blog.atom.io/2017/09/12/announcing-atom-ide.html http://blog.atom.io/2017/09/12/announcing-atom-ide.html - http://blog.atom.io/2017/11/15/code-together-in-real-time-with-teletype-for-atom.html http://blog.atom.io/2017/11/15/code-together-in-real-time-wi... Still beta, though.

wldcordeiro 9y ago
Eh I've been using it since release. They're great, especially the Flow language server! Only thing I recall missing from Nuclide was the in-editor Flow type coverage but if I recall they're planning to introduce it soon.
jonathankoren 9y ago
Neither of these are remote editing. The first one is a link to IDE cruft, and the second is collaborative editing with a a second full atom installation complete with another GUI for you to click "share" with. 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/ 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-through-ftp-sftp-in-atom-solved-with-nuclide/28781 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.
- dflock 9y ago
  I'm always a bit puzzled that people seem to want every editor to re-implement this same feature. What's wrong with sshfs? That does it at the OS level and it then works for everything?
  - moosingin3space 9y ago
    I've had issues where sshfs hangs in uninterruptible sleep if the connection is lost.
  - jonathankoren 9y ago
    sshfs is slow on macosx. Also, you have to remember to have a separate terminal opened on the remote machine if you want to do any git stuff. Using your local terminal and just cding into the mount point should work, but in practice it doesn't. The commands are just super laggy. 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.

by dflock 9y ago

wldcordeiro 9y ago

Eh I've been using it since release. They're great, especially the Flow language server! Only thing I recall missing from Nuclide was the in-editor Flow type coverage but if I recall they're planning to introduce it soon.

jonathankoren 9y ago

Neither of these are remote editing. The first one is a link to IDE cruft, and the second is collaborative editing with a a second full atom installation complete with another GUI for you to click "share" with. 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/ 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-through-ftp-sftp-in-atom-solved-with-nuclide/28781 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.

dflock 9y ago
I'm always a bit puzzled that people seem to want every editor to re-implement this same feature. What's wrong with sshfs? That does it at the OS level and it then works for everything?
- moosingin3space 9y ago
  I've had issues where sshfs hangs in uninterruptible sleep if the connection is lost.
- jonathankoren 9y ago
  sshfs is slow on macosx. Also, you have to remember to have a separate terminal opened on the remote machine if you want to do any git stuff. Using your local terminal and just cding into the mount point should work, but in practice it doesn't. The commands are just super laggy. 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.