Sublime Forum

on_window_command doesn't pick up show_overlay


A real shame and quite confusing. But am I missing something?



Maybe it is an ApplicationCommand, which can’t be intercepted?



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.



agreed, I requested this here:

1 Like


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:frowning:

1 Like


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 :slight_smile:

1 Like