Is there a global keycombo resolver/daemon



I have noticed, that many keycombos do not work globally
if a pane(search) or treeview is in focus.

I always expected that there is a central service which collects all keypresses,
and delegates the keycombos to the relevant subwindow,
but process the “global” keybindings (Ctrl-pgUp, Ctrl-PgDown, etc) without passing it.

Can somebody enlighten me how the keybinding processing is done in atom?
Maybe a global keybinding decider is needed, and some rethought is needed here?



A key is bound to elements that match a certain css selector. When a key-combo is pressed, an event triggers on the focused element and traverses up the DOM tree. When an element is found with a binding for that key-combo, the command is executed (and I think the DOM traversal is stopped, but I am unsure about this).

Because the atom-text-editor element is not an ancestor of the tree view, keybindings on the text-editor will never trigger when the tree view is focused.


Take a look at the documentation for Keymaps:

Especially the Specificity and Cascade Order section should help with clearing up your confusion why sometimes keybindings do not seem to work.

If you still have any questions feel free to ask!


Take a look at the documentation for Keymaps:

@olmokramer, @Alchiadus: After reading the above documentation and your comments it seems, the keybinding works exactly in reverse, what would be desirable, and in the current state it is not possible at all to define global keybindings.
(The first, most specific dom element consumes the key combo, and there is no global decider who may override/protect some global keybindings)

It suffers the exact same issue what normal firefox/chrome suffers. Ie. having a flash application in focus on the current page makes Ctrl-PgUp/Down non-working.

It is the same with atom. Having a widget in focus on the current page may result some “global” keybindings to stop working. The most prominent is Ctrl-PgUp and PgDown.

A workaround would be to define the exact same keybindings to each panel (file search, directory tree and main editor), but it is designed to be broken in future simply because it does not take into account there is a need for global keybindings.


There’s no global keybindings in the sense that it will trigger no matter what. This is to prevent multiple commands being executed upon pressing a certain keybinding. If you don’t like a keybinding added by a package, you’ll have to override or unset it yourself in your ~/.atom/keymap.cson.

I think this system works great, because it lets the users decide which keybindings are important to them, and customizing the keybindings is very easy.


@olmokramer: But maybe the user want to protect some of his keybindings.
So not allow to any package mess with it, and properly delegate these keybindings to a central decider, which may override some decision

with a nice warning message somehow. Ie.

The Ctrl-PgUp is also defined in XY package, but was supressed in favor of the global Ctrl-PgUp keycombo. >>Click here<< to alter the preference, or >>suppress<< this message in future.


Right now any package/subwindow may (accidentally) sink any keybinding event.


Then the user can unset those keybindings in their keymap.cson. If, for example, you’d want to remove the Ctrl+PgUp from the atom-text-editor element, you can do:

  'ctrl-pgup': 'unset!'


I looked up the pane:show-previous-item command, and the problem you’re experiencing has nothing to do with the keybinding, it’s because the command itself is added on the atom-pane element, i.e. the command will only work when a (child of) atom-pane is focused. The keybinding is bound to the body element, so it will trigger all the time.


Where is it in the source? I would like to check it also…


Which part do you mean? The keybinding registration, the command registration, the command registry in general or the keymap system? :smile: