3 ms·
Atom is my go to editor now. It’s simple, it’s pluggable, and modern. I really like it. I’ve been recently using it with FB’s Nuclide, but that’s such a massiv
by jonathankoren 9y ago
Atom is my go to editor now. It’s simple, it’s pluggable, and modern. I really like it.
I’ve been recently using it with FB’s Nuclide, but that’s such a massive suite of plugins, it might as well be a considered a derivative of it. I can’t recommend Nuclide. It’s bloated, and breaks a bunch of behavior from vanilla Atom, but it is the only thing that seems to get remote editing right. I just wish someone would get that piece out of put it as it’s own plugin.
- dflock 9y agoThey 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 agoEh 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 agoNeither 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 agoI'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 agoI've had issues where sshfs hangs in uninterruptible sleep if the connection is lost.
- jonathankoren 9y agosshfs 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.
- chillee 9y agoThere is indeed work at FB being done towards that last part.
- jonathankoren 9y agoWhere? Seriously, if there's a package, I want it. Quite frankly, I don't think FB cares enough to break remote editing out of their extant project which they really really like. There's no benefit to them.