8 ms·

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

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.

pjmlp 8y ago
We just use Vim or Emacs over SSH in such cases, or if the connection is good enough over X/RDP.
- josteink 8y ago
  With Emacs you use it locally and edit via tramp.
  - giancarlostoro 8y ago
    One of the main reasons I use Emacs whenever I do use Emacs. Though now I just do VS Code and X forwarding.
  - pjmlp 8y ago
    I never heard of tramp, thanks.
    - omaranto 8y ago
      You might enjoy Mike Zamansky's blog post and short video about it: http://cestlaz.github.io/posts/using-emacs-25-tramp/#.W2HhPHXOXCI 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/ 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.)
kristiandupont 8y ago
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?
- giancarlostoro 8y ago
  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).
  - ElCapitanMarkla 8y ago
    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.
    - giancarlostoro 8y ago
      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.
- simias 8y ago
  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.
zbentley 8y ago
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.
- spicyj 8y ago
  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.
- mraison 8y ago
  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.
taternuts 8y ago
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.
math0ne 8y ago
Can you explain a little more about the remote file editing workflow? Is there an article I can reference or something?
- mraison 8y ago
  The official documentation is here: https://nuclide.io/docs/features/remote/ 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-inotify-limits 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.

pjmlp 8y ago

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

josteink 8y ago
With Emacs you use it locally and edit via tramp.
- giancarlostoro 8y ago
  One of the main reasons I use Emacs whenever I do use Emacs. Though now I just do VS Code and X forwarding.
- pjmlp 8y ago
  I never heard of tramp, thanks.
  - omaranto 8y ago
    You might enjoy Mike Zamansky's blog post and short video about it: http://cestlaz.github.io/posts/using-emacs-25-tramp/#.W2HhPHXOXCI 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/ 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.)

kristiandupont 8y ago

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?

giancarlostoro 8y ago
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).
- ElCapitanMarkla 8y ago
  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.
  - giancarlostoro 8y ago
    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.
simias 8y ago
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.

zbentley 8y ago

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.

spicyj 8y ago
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.
mraison 8y ago
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.

taternuts 8y ago

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.

math0ne 8y ago

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

mraison 8y ago
The official documentation is here: https://nuclide.io/docs/features/remote/ 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-inotify-limits 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.