This is another reason for Jon to release ST as an open source project. The editor is extremely polished at this point, and now only new features and niche issues like Python modules should be added to the core codebase. I imagine that since ST is no longer growing as it was years ago, the future money flow is relatively insignificant.
Atom may have more momentum and plugins than Sublime right now, but since the core is built upon Chromium rather than Jon's custom beautiful and latency-free cross platform UI framework, it will never suit everyone's needs of performance and responsiveness. The world needs a good native, fast editor with a focus on mouse pointer editing, but only gvim is a viable (and bloated) contender.
Donations for software like this works fantastically, as I know from experience, and the increased momentum of an open source release would increase the number of commercial users willing to ethically support the project.
However, if it remains proprietary, ST is still a respectable editor I will be using for the next decade.
I've been using both Atom and Sublime Text 3 "in anger" over the last two months. As good as Atom has become now that it has reached 1.x, I find that the editor I turn to is Sublime. It just works.
subl . and poof, it's up in a directory
atom . 7 or 8 seconds later it's partly up...
I bought ST2 some time ago, and I'd buy ST3 if he pulled the trigger and moved it out of beta... But not if it truly is abandon-ware. I'm willing to pay for quality commercial software, and Sublime Text 3 is high-quality. But I want to know that the project hasn't been walked away from.
I give Atom a shot once in a while. Had week long atom periods 3-4 times now, always went back to ST3. However, this time i've been on it for a month or so. Haven't had a big complaint other that the boot time.
I think it's gonna start replacing ST as daily driver for a lot of people with this development pace.
Interesting articles, though I'm not sure the critique applies here. It seems rather, ST2 ships with a separate and incomplete python environment. I don't think it 'embeds' python, does it?
Yes, Sublime Text embeds Python. The Python interpreter is initialized by the Sublime Text binary.
The issues that Floobits ran into were some of the edge-cases related to distributing a compiled version of Python to various operating systems. I wrote a top-level comment on this page about how Package Control patches these issues.
Package control is usually one of the first three things I show to people new to Sublime. It's the best damn plugin system I've ever seen. Thank you for your work, Sir!
Note that this is mostly an issue for Sublime Text 2. Sublime Text 3, which is in beta, has a much more consistent Python 3 embed.
Unfortunately, ST3 is in one of those death-march betas that have been ongoing for years, fragmenting the plugin space. If you write a plugin for ST, you either need to write Python that simultaneously targets Python 2 and Python 3 (possible, but restrictive), or you need to maintain two versions of your plugin.
As of earlier in the year, over 80% of Package Control users were on ST3. ST2 usage seems to be waning pretty significantly. It will be nice once package developers can use all of the goodies in Python 3 and not worry about the ancient Python 2.6.
We did however have to use external python for the common python core instead of just importing the package, mainly because of the lack of ssl support in the embedded python.
My eyebrows lifted somewhat when I read that sentence. Bit of a bad case of "Works on my machine". Reminded me of an amusing blog post by Ted Dziuba [0], less so the rant about Apple kit, more about the mindset of certain groups of developers don't stop and think about where their shit will run before churning out 2 months worth of code that "worked on their machine".
This whole story seems like pretty poor form. You based your business, in part, on a closed-source product, failed to test your multi-platform product on... any of the other platforms you planned on releasing it for, and then wrote up a lengthy blog post blaming the author of same closed-source product for failing to address your pet issue, as if your business being dependent upon it being fixed should somehow be his concern.
> So... shipped multiplatform code without testing it on Windows and Linux?
I'm getting the feeling that these days anything a "ninja coder" has written on a Mac is assumed "good" because Mac is "Unix" and therefore the code "has" to be portable.
Is there something about the Mac culture which leads to less considerations about other environments?
Wait. Who in the hell releases something on multiple platforms without testing those platforms a single time?! O_o Multiple platform support has always, ALWAYS, required additional work on every project I've ever worked on. Often significant amounts.
When developing a Chrome extension or Firefox add-on or Greasemonkey script, do you test it on Windows, OS X, and Linux?
Sublime Text is the only editor we've had to build platform-specific workarounds for. Atom, Emacs, Neovim, IntelliJ and ilk (PyCharm, WebStorm, etc)... none of them have these sorts of bugs. (They have other bugs, but they're consistent across platforms.) Comments such as, "You didn't test it on every platform?!" are succumbing to hindsight bias.
Originally, our plugin just used the Python bundled with Sublime Text. Only after discovering these bugs did we add work-arounds that used the system Python.
Package Control has patched these two module issues for a while, but I figured I'd give some details for those that are interested:
Sublime Text 2 on Windows has an error when importing select. It isn't that Jon didn't include select, but rather there seems to be an issue importing the select.pyd from the folder that sublime_text.exe is located in, with Python 2.6. In fact, Python 2.6 on Windows has all sorts of issues that Jon burned a lot of time trying to work around. For instance, Python 2.6 can't add sys.path entries for folders with non-ascii characters. This led to a hacky work-around where Sublime Text chdirs into each package folder and loads the Python from ".\". Package Control solves the select import by shipping the select.pyd files, but placing them in a package folder and then adding that folder to sys.path.
For Linux, Python creates a _ssl.so shared library shim that links with the system's version of OpenSSL. The downside is that different distros have different versions of OpenSSL - 0.9.x and 1.x.x. This is further compounded by the fact that Fedora has their own specially numbered version of libssl (libssl-10 instead of libssl-1.0.0). So, by distributing a compiled version of Python, there isn't a way to ship the _ssl module for Python that will actually consistently work. Jon seems to have decided to focus his energy on other issues. Package Control patches this issue also. Actually, my SFTP package was the first to patch the issue, but I spent the time to make in generally available to all packages with Package Control 3.0.
So there are two options to deal with _ssl. Jon could try to ship OpenSSL with Sublime Text, thus entering the world of being responsible for patching OpenSSL, and dealing with dynamic linking issues and all that jazz. It gets kind of gross dealing with rpath and all kinds of other work to get the shared lib to look in the current folder first rather than loading the, possibly incorrect, system version of libssl. I've gone down that path before with a project and it was not a fun time. On a side note, Sublime Text on Windows unfortunately does ship OpenSSL, so the version available to Sublime Text plugins can be out-of-date. I've been working on a cross-platform crypto library for Python that uses the OS crypto facilities, which could be a solution for this in the future.
The other option is to rely on the system version of OpenSSL, but provide _ssl.so shims for each of the different major versions of OpenSSL for each architecture. Then ssl.py would have to be patched to try each of the shims until one of them loaded properly. The upside here is that the distro is responsible for updates to OpenSSL. This general approach is what Package Control does, however I don't patch ssl.py. Instead Package Control adds a custom package that is listed alphabetically first, and thus loaded by Sublime Text first. This custom package tries importing each of the shims until it finds one that works with the version of OpenSSL on the system. If you are morbidly curious, you can see the code and shims at https://github.com/codexns/sublime-ssl-linux.
The end result of all of this is that for the majority of ST users, these issues are likely solved. Package Control 3.0 automatically installs these fixes, and provides mechanisms for package developers to share other compiled Python modules. Older versions of Package Control have been EOLed, and thus it is possible for package developers to rely on users having these patches in place.
They developed and tested their software on Macs. Yet they offered it to Windows and Linux customers without ever doing any testing on those platforms? Isn't that like saying my React app works on IE-11 so I'm sure it must work on IE-6?
I mean, in the sense that technically when you publish anything on GitHub/npm/PyPI/RubyGems/etc. you're "offering" it to Windows and Linux users – sure. Given that the editor plugin is not a standalone software product being sold, it seems perfectly reasonable to just put it out there and then let people report issues on their platform.
I believe only ST 2 on OS X relies on the system python - 2.6 or whatever python happens to be in the path. Sublime 3 ships with python 3.3 on all platforms.
edit:
If you are asking about the Floobits plugin, ST 2 on OS X shells out to the system python (because of SSL).
I added a comment on this page that Package Control patches the select issue on ST2 for Windows (and explains it a little), plus includes shims for _ssl on Linux with details about how it works.
Importing select works in Sublime Text 3 on Windows. Unfortunately, many people still use ST2, since it's the default download on the Sublime Text website. It would make my life much easier if ST3 came out of beta.
Surely if they are devs they know they're not bound to the "default download".
I've been using ST3 dev builds for what, 2 years now? Rock solid all this time on OS X (with around 10 plugins). Only had one issue (high cpu load on search IIRC), that was corrected by going back to the ST3 beta for the 2-3 days it took for it to be fixed.
I'm in the same boat. I use ST3 as my primary editor and it's been quite stable.
The ST2 users are part of a significant chunk of developers who just use defaults. They use the default shell, default themes, default mail/calendar/IM client, etc. They don't toolsmith. Their motto is, "If it ain't broke, don't fix it."
Considering the annoyance of dealing with unstable software, I can't blame them... much.
Atom may have more momentum and plugins than Sublime right now, but since the core is built upon Chromium rather than Jon's custom beautiful and latency-free cross platform UI framework, it will never suit everyone's needs of performance and responsiveness. The world needs a good native, fast editor with a focus on mouse pointer editing, but only gvim is a viable (and bloated) contender.
Donations for software like this works fantastically, as I know from experience, and the increased momentum of an open source release would increase the number of commercial users willing to ethically support the project. However, if it remains proprietary, ST is still a respectable editor I will be using for the next decade.