I really, really wish it was open source. I understand why it isn't, but with its main competitors being Atom and VSCode, it's hard to warrant using a closed source text editor even if it's so much faster and I'm used to it.
If I have ssh access, I use sshfs to edit remote files with my local copy of Sublime. I also set up a Sublime build system that calls the compiler remotely over ssh. After I set my ssh config to cache and reuse connections, it adds virtually no overhead. Builds are one keystroke, errors show up in the editor just like normal, and small builds can still be done in just a fraction of a second.
The only problem with this setup is that sshfs is bad at recovering from network errors. If someone made a version of sshfs that could automatically reconnect after an interruption then this setup would be practically indistinguishable from working locally, even on moderately high latency connections.
You likely have already tried this, but in case you haven't: sshfs has a mount option -o reconnect which tries to be a bit more resilient about this sort of thing.
I have to admit I was little worried about using Sublime because it was closed source and I had no idea how often it would phone home to say hello / record keystrokes, but I used it and was so impressed by how fast it was. It was an order of magnitude faster than Atom. I would set up a Samba share on a linux box, connect to it, and edit files. My linux box would be the server I would use and samba seemed to solve that ok. How is sshfs compared to Samba?
Not OP, but SSHFS is really nice. You can stand it up in basically one command, and tear it down similarly when you're done -- no need to worry about setting anything up on the server side as long as you have SSH access.
Only if you have a single, constant remote. I've used osx fuse + Sublime a lot. It's not perfect. If you change something on the remote through not-sublime, sublime doesn't pick up changes for a long time (rather, your OS doesnt, not Sublime's fault).
That said, decent for the day to day. If you're hitting moving target servers, docker, etc, you still need to have some basic vim or emacs or nano knowledge.
It's more that the Fuse doesn't get signals from the remote host, so if you change data on the remote then fuse won't pick up changes even close to immediately without a restart
As far as I'm concerned, Atom isn't even in the running. It's clunky, and slow. VS Code is awesome, but is missing some crucial plugins that Sublime has. Namely proper SFTP support. The only one available is junk, and it regularly crashes the entire app with only attempting to sync a few hundred files.
Not it really is not. You simply use whatever fits your needs.
The same can be said about steep learning curve for VIM/Emacs. What's the reason for Atom/VSCode if Emacs/VIM can do it much better / faster.
Even opening large files on Emacs is flawless with vlf.
You may be interested in [LimeText](https://github.com/limetext/lime), if it ever gets to a usable state.
It's aiming to be a open-source clone of Sublime.
It's very much alive. You are looking at the meta project. If you look at the other components ( https://github.com/limetext ), there are recent commits.
People are downvoting you, but I think it's a legitimate point. For a stable project in maintenance mode, sure 28 days means very little, but for up-and-coming open-source clone of a major text editor it doesn't smell like critical mass.
That's exactly it. When someone suggests a project trying to compete and clone sublime text I expect it to be actively doing so, not doing so a month ago.
