Intercept all keypresses in a view

[wuub]

Is there a way to intercept all (or almost all) keyboard events in a given view with a plugin?

It seems that Vintage just rebinds keys if settings.command_mode is set to true. But what if I want to process it all?

Is generating an enormous .sublime-keymap my only option?

[quarnster]

I don't have an answer, but a similar problem. Vintage seems to eat my "enter" events in a specific view. I have the following in my Default.sublime-keymap for my plugin:

Code: Select all

    {
        "command": "gdb_edit_register",
        "keys": ["enter"],
        "context": [{"key": "gdb_running"}, {"key": "gdb_register_view"}]
    },
    {
        "command": "gdb_edit_variable",
        "keys": ["enter"],
        "context": [{"key": "gdb_running"}, {"key": "gdb_variables_view"}]
    },

and in my EventListener:

Code: Select all

class GdbEventListener(sublime_plugin.EventListener):
    def on_query_context(self, view, key, operator, operand, match_all):
        print "key: %s" % key
        if key == "gdb_running":
            return is_running()
        elif key == "gdb_variables_view":
            print "querying gdb_variables_view"
            return gdb_variables_view.is_open() and view.id() == gdb_variables_view.get_view().id()
        elif key == "gdb_register_view":
            print "querying gdb_register_view"
            return gdb_register_view.is_open() and view.id() == gdb_register_view.get_view().id()
        print "unknown query: %s" % key
        return None

With sublime.log_commands(True) I get this when pressing enter in the register view:

Code: Select all

key: gdb_running
key: gdb_variables_view
querying gdb_variables_view
command: set_motion {"motion": "move", "motion_args": {"by": "lines", "extend": true, "forward": true}}


So "gdb_register_view" is never queried, but "gdb_variables_view" is... Is there anything I can do to fix this? Thanks

[castles_made_of_sand]

You know that bindings are all collected into one big array from all the keymaps in the order of `Default/PackageA ... PackageZ/User`?

They are then matched in reverse order, `User/PackageZ...PackageA/Default`, taking the first that matches.

Code: Select all

>>> 'V' > 'S'
True

Vintage comes after SublimeGDB in the load order, so will be matched against first.

Code: Select all

   { "keys": ["enter"], "command": "set_motion", "args": {
      "motion": "move",
      "motion_args": {"by": "lines", "forward": true, "extend": true }},
      "context": [{"key": "setting.command_mode"}]
   },

Your views must have `command_mode` set somehow? You are using Vintage or the plugin sets it? I looked over your code and it doesn't use command_mode so I'm guessing you use Vintage with `"vintage_start_in_command_mode": true`? That setting mostly effects files `on_load`, which I don't think would kick in for scratch views but I guess the following code, would put ALL files into command_mode.

Code: Select all

class InputStateTracker(sublime_plugin.EventListener):
    def __init__(self):
        for w in sublime.windows():
            for v in w.views():
                if v.settings().get("vintage_start_in_command_mode"):
                    v.settings().set('command_mode', True)


Your plugin keeps the panels between sessions?

Code: Select all

querying gdb_variables_view

That's quite odd. I can't really make sense of that at the moment. I always thought the binding matching was synchronous. ie, the on_query_context wouldn't be callled until it was required. With your bindings being below the Vintage binding in the stack, ("in my Default.sublime-keymap for my plugin") I dunno why it's callled at all.

Anyway, I'd try putting your bindings inside the User/Default.sublime-keymap file. That should take priority over Vintage then. If the bindings work then, you might have to consider renaming your package if you don't want people to have to manually move the bindings into their User keymap (and maintain them between updates)

Code: Select all

>>> new_package_name = 'ZSublimeGDB'
>>> cmp(new_package_name, 'Vintage')
1


[quarnster]

I'm using Vintage and command `"vintage_start_in_command_mode": true` in my user settings. Since my plugin "owns" the views created (and they are all non-editable), doing v.settings().set('command_mode', False) works perfectly fine for my use case.

That gdb_variables_view is queried but gdb_register_view isn't is odd indeed...

Thanks for your help!

[castles_made_of_sand]

>>> Since my plugin "owns" the views created (and they are all non-editable), doing v.settings().set('command_mode', False) works perfectly fine for my use case.

I was wondering about that. Wasn't sure what you were actually using enter for, or, being that you are a Vintage user, if you might need the Vintage binding.

>>> That gdb_variables_view is queried but gdb_register_view isn't is odd indeed...

A head scratcher. Used to think I had reasonable grip on how the bindings worked. Now, I have to go and rethink my life

>>> Thanks for your help!

No wukkin fuzzas

[Booger12]

For a certain Qt widget I'm writing, I need to intercept all keypresses while it has focus. How would I go about doing this?

_________________________________
Ed causes

[wuub]

For a certain Qt widget I'm writing, I need to intercept all keypresses while it has focus. How would I go about doing this?

AFAIK this is the only way: https://github.com/wuub/SublimePTY/blob ... ime-keymap