A real shame and quite confusing. But am I missing something?
on_window_command doesn't pick up show_overlay
That’d make sense, and wouldn’t. It’d make sense that an ApplicationCommand
is not intercepted, but why would show_overlay
be an ApplicationCommand
?
That was my first guess but there’s no way to tell.
It would be helpful if the logging enabled by sublime.log_commands(…) displayed the type of command, e.g., view, window, application (if that’s in fact what is happening).
The reason I want to know when the overlay opens is so that I can NOT intercept key strokes for a particular portion of my plugin. You’d think I’d be able to do that with the “context” part of the key binding, but it doesn’t seem to work for me for some reason. Maybe … I should try harder with tracking that down, but it’s hard to debug that stuff some times.
Actually it’s possible.
>>> view.run_command('show_overlay', {"overlay": "command_palette"})
>>> window.run_command('show_overlay', {"overlay": "command_palette"})
>>> sublime.run_command('show_overlay', {"overlay": "command_palette"})
And, weirdly, that’s the window
one that works…
in that case, I got no idea why on_window_command
or on_post_window_command
don’t get fired for show_overlay
…
I thought the same thing, but I tried creating a simple application command and it triggered the event listener. I can only imagine that internally that command isn’t following the same path through the command system (possibly due to a bug/oversight or possibly to ensure that nobody can mess with the popup showing up).
Some commands just do not trigger the on_*_command hooks. I think the save
command is also affected by this, but there is no exact list of this.
at least one can still use the event listeners on_pre_save_async
and on_post_save_async
for the save
command