That's not false – but it ignores the point the grandparent was making, which is that minimizing switch cost is valuable to some.

Switch-cost between what? Vim has worked pretty well for me for all programming languages I've used and on all platforms I've used. I reread grandparents comment and I'm a bit unsure what you are referring to exactly.

I'm just saying that you're hijacking the point (that using a single editor, rather than switching between IDEs, is useful) and replacing it with a competition for size and speed. Yes, vim and emacs are lighter. Does that devalue Atom's consistency? No. I say this as an avid Emacs user.

Ah, I understand now.

I guess my point was that since vim/emacs already exist and have advantages, that use case for atom seems a bit unnecessary, but of course in reality many people don't use vim/emacs due to the learning curve, so I suppose the point is irrelevant.

Well, I am editing remote code over SSH with Atom and Nuclide right now. It's been possible for a long time. Now you can even run a remote debugger on your Python program.

Ok, I take that back then. Vim/emacs only have a weight/speed advantage then.

I do, however, find it useful that I can be ssh'd into a machine, doing stuff in bash, and I can fire up vi. I suppose that's a separate discussion though.

Emacs has Tramp, which lets you edit files, manipulate directories (with dired), and do many other stuff you normally do on files seamlessly on remotes of all kinds, including ssh. If you're using emacs like vi where you start it up for each file and close when you save, you're extracting no value out of it, just use Zile.

This feature is somewhat less useful with the advent of sshfs.

It depends on what you do with it, as it does more than ssh. For example there's /sudo:: with which you can edit local files as other users. Also I have links to remote files in my Org files, and if I have ssh-agent running (which I always do), all I have to do to go to that file/directory is to click the link.

I've been wondering if there's a way to use a more graphical editor over SSH, such as vscode or sublime. I get that I could just "learn VIM" but I already know a shitload of hotkeys for vscode/sublime (they're easily transferred), so I'd rather just use them.

Just mount your remote folder with sshfs [1] and enjoy your local toolshed :) . X forwarding is overkill when all you need is accessing files.

[1] https://github.com/libfuse/sshfs , packaged by your distribution

Agreed. SSHFS is the way to go.

Learning Vim -- even the smallest subset of it -- will continue to pay off years into the future! Then you can combine it with existing Atom/Sublime/VSCode keymaps where need be and really have a nice fusion of functionality.

(VSCode vim mode is A+ btw)

I gave VSCode's vim mode a shot a few months ago and found it nowhere near Atom's vim-mode-plus. Has it gotten better?

Well, I think it has (I'm one of the developers). Since the beginning of April there's been over 149 pull requests merged. It's definitely gotten better.

You can open the file via SSH but use a local copy of VSCode/Sublime: https://codepen.io/ginfuru/post/remote-editing-files-with-ss...

Nuclide has pretty good support for remote editing (it's Facebook's "official" code editor internally), and VSCode is adding similar functionality. https://github.com/Microsoft/vscode/pull/30337

You could do X forwarding

Electron apps are terrible with X forwarding. Even locally, on your own LAN.

It's all rendered bitmaps getting sent over, causing much lag and terrible performance.

Not recommended.

Surprising, considering it's origin from web tech.

> Surprising

Or not, your forcing rendered html/dom over the x window protocol. What web tech is in this stack? Only your rendered app on a gtk/qt/wtk(not sure what atom is using, etc) window. Nothing on the network side.

mmm I wanted to edit my post but it seems to get locked after time. So just adding a comment with some info and corrections on the topic.

- Atom on linux uses GTK+[0].

- GTK+ uses XLib[1].

- From the wikipedia link "Xlib makes the client synchronous with respect to replies and events." so much for js being async ;)

- Do anybody know how workable chrome or even firefox is over the x window protocol?

[0]: https://electron.atom.io/docs/development/build-instructions...

[1]: https://en.wikipedia.org/wiki/X_Window_System_core_protocol#...

My vim process comes to a crawl if I forget to turn off syntax highlighting before opening large files. So I disagree.

That has not been my experience with vim (over the past ~12 years). I don't run a huge amount of plugins, but I do use a few. The only thing I have a noticeable occasional lag with is the parinfer clojure plugin (in neovim, and its more that the plugin lags before applying its changes rather than vim itself lagging - the author does acknowledge that its currently sub-optimal). Syntax highlighting has never caused any issues for me. I wonder why you are having issues... that does sound rather annoying.

I was also referring to the typing latency as measured by the benchmarks here: https://pavelfatin.com/typing-with-pleasure/ As you can see, vim's text input latency is measurably lower than most of the other tested editors on most platforms (zero-latency IDEA seems to beat it in some cases).

That’s a broken highlight syntax file. The good ones don’t highlight text until it becomes visible in the buffer. You should bug it if it is reproducible in neovim. The team is highly responsive.

It happens with large javascript files (bundles). I use this:

https://github.com/othree/yajs.vim

And my color scheme is:

https://github.com/nanotech/jellybeans.vim

Not sure which is at fault (if either).

Yeah, yajs hurts performance. There's actually a disclaimer on that landing page you sent me.

Neovim has its own js/json highlighting out of the box and it's pretty crazy fast for me.