Plugin Porting Guide
Sublime Text 3 contains some important differences from Sublime Text 2 when it comes to plugins, and most plugins will require at least a small amount porting to work. The changes are:
Sublime Text 3 uses Python 3.3, while Sublime Text 2 used Python 2.6. Furthermore, on Mac, the system build of Python is no longer used, instead Sublime Text is bundled with its own version. Windows and Linux are also bundled with their own version, as they were previously.
Out of Process Plugins🔗
Plugins are now run in a separate process,
plugin_host. From a plugin
authors perspective, there should be no observable difference, except that a
crash in the plugin host will no longer bring down the main application.
In Sublime Text 2, only the
set_timeout() method was thread-safe. In Sublime
Text 3, every API method is thread-safe. Furthermore, there are now
asynchronous event handlers, to make writing non-blocking code easier:
When writing threaded code, keep in mind that the buffer will be changing underneath you as your function runs.
end_edit() are no longer directly accessible, except in
some special circumstances. The only way to get a valid instance of an
sublime.Edit object is to place your code in a
subclass. In general, most code can be refactored by placing the code between
end_edit() in a
sublime_plugin.TextCommand, and then
running the command via
This approach removes the issue of dangling
sublime.Edit objects, and ensures
the repeat command and macros work as they should.
Packages in Sublime Text 3 are able to be run from .sublime-package (i.e., renamed .zip files) files directly, in contrast to Sublime Text 2, which unzipped them prior to running.
While in most changes this should lead to no differences, it is important to keep this in mind if you are accessing files in your package.
Importing other plugins is simpler and more robust in Sublime Text 3, and can be
done with a regular import statement, e.g.,
import Default.comment will
Restricted API Usage at Startup🔗
Due to the
plugin_host loading asynchronously, it is not possible to use the
API at import time. This means that all top-level statements in your module
must not call any functions from the
sublime module. During startup, the API
is in a dormant state, and will silently ignore any requests made.