[quote=“jps”]Dev Build 2156 is out now.
2156 features a new UI theme. One of the unique aspects of this theme is the way the tabs adapt to the current file’s color scheme. It’s been in the works for a long time, but I hope you’ll agree it’s worth the wait.
Also worth noting is the sublime.log_input(flag) function. By entering sublime.log_input(True) in the console, every key press will be logged to the console, helping you work out the name of the key to use in a key binding.
For API developers, there’s now a requirement that all event handlers complete in a short amount of time (16ms for frequent events such as on_modified and on_selection_modified, 200ms for other events). It’s been a long standing issue that a user can unknowingly install a plugin that makes the editor sluggish on large files, but the cause hasn’t been immediately evident to the user.[/quote]
FWIW, in my case at least… this feature doesn’t work at all. I saw the pop-up once, in flagging my plugin when it theoretically wasn’t running.
By that I mean, there were no .go files loaded so I shouldn’t ever see a source.go scope and there not run. In fact, it didn’t come from my plugin doing anything, it was simply checking the scope and possibly due to the heavy disk usage at the time the ST2 api was slow to respond.
I confirmed it doesn’t detect my slow plugin because the slow operation was run via a sublime.set_timeout so if I sleep a couple seconds, the ui is a little unresponsive as expected but nothing is detected(expectedly).
In the mean-time I moved that stuff off into its own thread even though I was a little reluctant to do so still, because I don’t want to introduce any instability into the editor(which is why it was run from a sublime.set_timeout).
I don’t know if anything has changed recently but IIRC when I just started writing the plugin a few months ago, I was told that there was no way to denote that a plugin should run only in a certain scopes(like we can do with key bindings) so I had to check the scope myself, meaning it’s always running.
I think what would be cool is if we could have something akin to set_timeout(or set_timeout itself) where we could schedule some function to run and the editor would run it such that it doesn’t make the ui unresponsive, that way we don’t have to mess with threads and the nightmare that they come with.
I will file a couple reports of how ST2 freezes the ui in its own operations.