The one reason I'm still using Atom is because of the remote editing experience with Nuclide + Watchman server-side. No other editor that I've tried comes even close (the connection drops, files get out of sync, new files don't show up, etc, etc)

Given the huge number of people who work on remote servers, I find it surprising that proper solutions are still so hard to find. A "file system provider API" for VSCode is in the works so I'm hopeful for the future.

I am curious about your situation that causes you to edit files remotely. I've never had to edit files anywhere but my local file system. Are you developing or is it more of a devops/sysadmin kind of role?

I definitely use tramp a lot to remote edit files in Emacs. I suspect it depends heavily on the type of application your develop and your workflow, but it might also be that if you never really had the possibility to do that easily you might never really realize what you're missing since you're used to do things differently. It's a bit like X forwarding in that respect.

To give you an example of what you can do I often use tramp locally to edit files as root: instead of having to fire a different instance of an editor as root to edit a config file I can just do it "remotely" from my main Emacs instance, with all my config and without worrying about messing something up by having the entire editor running privileged.

I work in embedded development so I also often use it to browse and edit files on the live target system (beats using a crappy dumbed down vi from busybox). And of course as you mention for general sysadmin tasks it's also great, I'm a developer but that doesn't mean that I don't have some sysadmin to do from time to time.

I have to do it all the time cause I want to develop on a VM that matches the target platform for my project. Usually involves figuring out how to debug things. My solution is to install VS Code on remote system and use X forwarding depending on project. I also use PyCharm Pro so in such case I use Vagrant and it does its thing but it syncs awfully as OP mentions so debugging can become extremely painful idk why JetBrains has not fixed said issue customers have complained (remote SSH / Vagrant support is part of their paid tier).

This is my scenario at the mo, I've tried syncing the code dirs between the VM and my local machine but I haven't found a nice solution for that.

My current solution is just SSH/Vim but I think I'd like to go back to a graphical editor. I like Vim but sometimes it's a hassle on the big projects.

I use Vagrant w/ VirtualBox and setup shared folders, but it's not as nice when you want to debug or execute code. PyCharm Pro has great support for Vagrant though it sucks at updating certain things on the server end.

One reason I use it is if I am working on an embedded device. Sometime I just want to go in and try a concept out that I couldn't just spin virtual machine up for.

I'm developing. It's useful whenever I need to work on a machine with a specific environment and/or more bulky hardware than what's available on my laptop.

I've spent a lot of time trying to get a proper remote-editing/incremental sync setup working. That sounds really interesting to me.

How many files are you able to handle, remotely, with Nuclide/Watchman?

Does it work if the remote files are on an NFS share (i.e. spotty inotify/fanotify support) mounted onto the server you're SSHing into (no, the NFS share cannot be mounted directly on the workstation)?

How many file-change events (on your workstation or on the remote) can this system successfully sync/handle in a short time? If there is, say, a 250k file alteration that happens due to checking out a branch, is there an indication that it detected the changes and is making progress syncing them, or does that necessitate a manual sync?

Context: I've worked in environments where local editing and manual sync got really annoying: for compliance/regulatory reasons, certain tools, e.g. source control, were only available on the remote server, so having all code on my laptop and manually syncing to the remote got quite tedious. Even better, the significant (i.e. I might conceivably need to open them/run tests that touch them) number of source files in the remote repo was in the tens of millions. I wasn't able to get any incremental sync/change-detection systems working successfully: on my workstation (OSX), large changes would overflow the fsnotify kqueue, no matter what wrapper around it I used. On the remote, watching was either unavailable (due to the age of the Linux server) or prone to failures in the event of large changes in files (e.g. checking out a new branch).

I've spent a lot of time mucking about with lsyncd, unison, and lots of other tools, and eventually gave up with the conclusion that directory-diffing is too slow given slow remote filesystems, and change notification systems aren't up to the task of managing bulk changes across a huge repo. Watchman sounds really promising here; I'd love to hear more about your experiences with it.

I don't think I've reached the limit of how many files Nuclide/Watchman can handle, everything is perfectly smooth with very large codebases.

However, things don't work as well with an NFS share and I think you get an explicit warning when you try to do it.

At Facebook most of our thousands of web devs use Nuclide for remote editing on a repo with hundreds of thousands (or millions) of files and it works as advertised. We don’t use NFS though; all the repo checkouts are on disk on the remote machine.

I've got a couple co-workers who feel the same. I've always just used ssh/vim in such cases, but apparently the remote-editing experience on VSCode isn't nearly as good as that of Atom for some reason. Otherwise, I really love VSCode, the only thing it lacks for me now is the ability to separate tabs into different instances/windows but that's more of an electron issue. I've pretty much stopped using jetbrain's products in favor of it.

Can you explain a little more about the remote file editing workflow? Is there an article I can reference or something?

The official documentation is here: https://nuclide.io/docs/features/remote/

One of the steps is to install Watchman. If your remote server is on Linux, make sure to read that part of the docs: http://facebook.github.io/watchman/docs/install.html#linux-i... (In my case I just set the three settings to 999999)

Finally, you may need to create a .watchmanconfig file at the root of the folder you're working on.

We just use Vim or Emacs over SSH in such cases, or if the connection is good enough over X/RDP.

With Emacs you use it locally and edit via tramp.

One of the main reasons I use Emacs whenever I do use Emacs. Though now I just do VS Code and X forwarding.

I never heard of tramp, thanks.

You might enjoy Mike Zamansky's blog post and short video about it: http://cestlaz.github.io/posts/using-emacs-25-tramp/#.W2HhPH...

Also, the manual is pretty good. It comes with Emacs, of course, or can be read at https://www.gnu.org/software/tramp/

My favorite thing about TRAMP is how well integrated it is. It's not just opening remote files, you can also open shells on remote systems, or do file management with dired (I have a bookmark pointing to dired on a remote system I use frequently, for example.)

We've also been in the same boat as you guys. Starting to just look into VSCode as an alternative, then immediately switching to it after realising the performance difference is like night and day.

Since Atom doesn't provide anything that we can't install in VSCode as a plugin, there really is no reason to use Atom right now. The only problem I had with VSCode was the default interface, that I modified with plugins until it pretty much looks like Atom, but runs way faster.

I still use Atom mostly because of the default interface. Care to list the plugins that you used?

Of course. The most useful ones are the following:

- Bracket Pair Colorizer

- EditorConfig for VS Code

- ESLint

- Git Blame

- Material Icon Theme

- Path Intellisense

- Prettier - Code Formatter

- SCSS IntelliSense

- TSLInt

- Winter is Coming Theme by John Papa

Emmet.

I get why people use it, I just don't have any use case for it. I'd rather write my code myself instead. Just a personal preference though.

I don't find the code generation stuff that useful but I found it useful for its text manipulation features - like selecting all text within 2 nodes, editing a start and end tag at once.

To each his preference, I suppose. But I definitely could imagine a far more difficult life without Emmet.

I've a similar story and several teams at our company have switched to VS Code independently. There are some Atom "believers" though.

I hope github is going to continue working on Atom independently from MSFT. Competition is a good thing. But since both products target the same audience, from Microsoft's perspective I'd understand if they'd bring those brilliant minds together in one team.

For what is worth, in an AmA Nat Friedman stated that development of Atom will continue "as long as there's people using it", and they will probably share some code between vscode and atom (they already do)

I've bounced back and forth between Atom and VSCode - the main reason for me has been bugginess with prettier plugins. I've had more weird issues with the VSCode one, so I've leaned more on Atom.

Perf for VSCode is definitely much better though.

Is this still true? I tried Vscode / Atom the other night and Atom performed better for me, at least for the time it took to render the syntax highlighting of each file.

I had a similar experience with performance was an issue for me so I switched over. Never went to back to test any of their newer releases.

Sadly, no. I tried it out again a couple of days ago and the performance is still terrible. I'm in the same boat as you and switched to VS Code.

I hope xray[1] catches up. I prefer atom's UX-UI to any other editor but I agree that performance is still an issue. MS taking over Github doesn't seem to bring to a bright future. I really hope I'm wrong.

[1] https://github.com/atom/xray

With xray focusing away from improving the editor experience and more on this new version control thing [1] for now, it doesn't seem like we'll be seeing a GitHub-provided alternative to Atom for some time.

[1] https://github.com/atom/xray/blob/master/docs/updates/2018_0...

In an AMA the future CTO said they would never get into text editor politics by merging the two or taking one away. Both editors will remain.

I have the same question. I've never bothered looking back extensively at Atom since using VS Code.

Similar history with Atom, but I haven't looked back after switching to spacemacs :)