Keymap cascade order



This page mentions a keymap “cascade order” that Atom uses to determine which of 2 key bindings takes precedence when they have the same selector (or same specificity). What is this order exactly?

I would expect key bindings from a package to take precedence over built-in ones, but this does not seem to be the case. I can see both are defined in settings, but the built-in one wins. Is this a bug?


How can I change the keymap to have Delete Line working with cmd-d?
How can I change the keymap to have Delete Line working with cmd-d?
Changing the Keymap for Tree View:Toggle?

The keybindings selector specificity plays a part in this as well. For example, if Atom binds a keystroke to .workspace .editor and you bind it to .editor the atom binding will always take precedent because it has a higher selector specificity.

You can use the Keybinding Resolver cmd-. to figure out which selector is being chosen.


Thanks ProbablyCorey. I didn’t know about cmd-. – that’s really helpful.

I get the specificity thing, but it looks like if a core key binding and a package one have the same specificity, the core one wins. Or at best it’s nondeterministic. I think it would be good to have a priority order for bindings at the same specificity like: built-in (low) -> packages -> personal (high).


it looks like you can use !important to explicitly override. I had to do that to get cmd+d mapped to delete-line. Nothing else I tried would win over the core selector.