TL;DR: I don’t think there is currently a good resource for this, ST2 plugin development is not as different as you might think it is, and it’s doubtful that plugin development is dead based on the number of new packages that are coming out every day. The official documentation is sparse-ish, the unofficial documentation is more detailed, but together they contain the information you need, just not step by step instructions, so you should also look at some practical examples to see how things fit together and help yourself understand better.
I don’t know that there are any official sources short of what you’ve already noticed. I’m currently working on a tutorial video series on the subject, but that’s not likely to help you in the short term. It would be helpful to know what you think is missing or what you’d like to see in this regard, though.
If it helps, the official documentation contains a porting guide that tells you how to port a plugin from Sublime 2 to Sublime 3, which is (paraphrased):
-
Python 3.3 is used instead of Python 2, so syntax and libraries change accordingly
-
Plugins are now executed in an external process for isolation so they can’t crash Sublime; this has no practical effect on you as a plugin developer
-
As part of #2, the API is not immediately available when your .py file is loaded; if you need to do any set up work at load time, define a plugin_loaded() top level function in the module
-
The API is more threadsafe than it was before, so older code will still work but newer code is easier to write in this regard
-
Some of the existing events now also have async variants that automatically run in another thread to save you time if you’re doing something lengthy and don’t want to block the UI.
-
Sublime 3 can run packages from sublime-package (i.e. zip) files instead of having to unpack them first; if you write a plugin that needs to access files within a package, use the API to get at the resource and don’t blindly assume the files will be sitting unpacked on the file system.
-
You cannot create edit objects at will; define a TextCommand if you need to directly modify a buffer to be given one directly by Sublime.
That is, things are mostly the same except in ways that don’t directly matter to you a lot of the time, presuming you’re familiar enough with Python to be able to convert whatever might be different about Python 2 to Python 3.
On the whole your biggest sticking point is going to be #7, edit objects. You need to pass one to any API functions that modify the contents of a file, and where you used to be able to create them with impunity you now have to rely on Sublime giving you one as part of a TextCommand, so any older code you see would need to be refactored a bit.
To your other questions, is plugin development dead? I highly doubt it. Potentially there’s not a lot of ST3 specific documentation because things more or less work the same as they used to, or nobody has stepped up with a recent set of tutorials because of other reasons. The new packages section of the Package Control website is constantly getting new packages added, for example.
The official documentation isn’t open sourced in a place where contributions can be directly made. On the other hand, the unofficial documentation is definitely open to pull requests.
If you want to get started in plugin/package development my advice would be:
- Read through the Unofficial Docs to get a handle on all of the different resource types that a package can contain and what they’re for
- Read through the Official Docs, including the API documentation page so you can get a vague sense in your head about what the plugin API is capable of
- Use
View Package File from the command palette to look at the .py plugins that ship with Sublime to get a sense for how the API fits together.
In short, package development is a complicated topic to describe, document and teach because, more or less, everything relies on you knowing something else before you can fully understand what it is and what it’s for.
As such, there’s not a set of pages where you just read it from the top to the bottom and now you know how to develop plugins. After you read through all of the items above, there’s going to be a bunch of stuff that you don’t fully understand or flat out can’t tell what the hell it’s even talking about.
However as you work through simple plugins, look at samples, and then go back to the documentation, you’ll find that every time you go back you understand more than you thought the first time through.
