11–20 of 46 posts
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.
Glyph Lefkowitz warned about the dangers of embedding Python a long time ago: https://twistedmatrix.com/users/glyph/rant/extendit.html See also this comment of his on Advogato, which he indirectly referenced in the previous article: http://advogato.org/article/550.html#12
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?
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.
So... shipped multiplatform code without testing it on Windows and Linux?
[0]: http://widgetsandshit.com/teddziuba/2011/03/osx-unsuitable-w...
So... shipped multiplatform code without testing it on Windows and Linux?
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…
I'd be content with source available to licensed users- I've already sunk money into it, why not bug fixes?
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…
subl . and poof, it's up in a directory
atom . 7 or 8 seconds later it's partly up...
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.
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…
So this relies on having a system version of python but there's no mention of that requirement anywhere in the repo...
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).