There is always one instance of a TextCommand for every view, one instance of WindowCommand for every window and one instance of ApplicationCommand for the whole application created. The creation is triggered by the plugin being loaded, not by the command being run (in general, but see below).
That is, once a command instance is created for a thing, it remains in existence until that thing goes away; it doesn’t get created again for the same thing unless the plugin that provided the command gets reloaded.
That said, Sublime is a bit “lazy” about command instantiations sometimes, which can give the impression that it’s creating commands more often than you might think. The general assumption should be that you don’t know when exactly a command will be instantiated for any particular thing, but you can be assured that it will exist at least at the point where it’s executed and that it will remain in existence for conceivably forever barring plugin or package upgrades.
For example, given the following sample plugin:
import sublime
import sublime_plugin
class ExampleOneCommand(sublime_plugin.TextCommand):
def __init__(self, view):
super().__init__(view)
print("New Text Command")
def run(self, edit):
pass
class ExampleTwoCommand(sublime_plugin.WindowCommand):
def __init__(self, window):
super().__init__(window)
print("New Window Command")
def run(self):
pass
class ExampleThreeCommand(sublime_plugin.ApplicationCommand):
def __init__(self):
super().__init__()
print("New Application Command")
def run(self):
pass
With this in place, starting Sublime with three windows and 4 open files displays this in the console:
plugins loaded
New Text Command
New Text Command
New Application Command
The numbers there don’t really add up; there aren’t even any WindowCommand instances created. However when you give the focus to one of the other windows, you can see more commands being created:
New Text Command
New Window Command
New Text Command
New Window Command
This behaviour only really holds when plugins are loaded/reloaded, which means that it tends to be lazy both at startup and when a plugin updates and new command instances need to be created.
Outside of that situation, every time you create a new tab a new TextCommand instance is created for it, and every time you open a new window a new WindowCommand instance is created for it; at least as far as I’ve personally witnessed, which is somewhat anecdotal.
In any case, running the command doesn’t necessarily create a new command unless that view or window didn’t already have an instance created for it:
>>> window.run_command("example_two")
>>> window.run_command("example_two")
>>> window.run_command("example_two")
>>> window.run_command("example_two")
>>> window.run_command("example_two")
This property allows commands to retain state between invocations, if you’re so inclined to do so, so long as you’re aware that there may be points where the persistent state is lost (at startup or package reload time). In cases like that it’s probably not a good idea to rely on this mechanism for persistence and you should use some other mechanism. The same could be said for creating global objects as well, though.
You would need to use some external global state if you needed more than one command to also have access to it, however. Without your intervention instances of classes created for different view or window objects don’t know about each other’s existence.
Possibly a static class variable could be useful in such a case, if your use case permits.
