Announce: Search-All-Keybindings


From readme …


Atom editor package developer tool to search all published keybindings

search-all-keybindings is an Atom editor package that allows a package developer to search through all published packages. This allows you to find out if a planned binding in your package has significant conflicts with other packages. At the time of this writing there are over 1900 keybindings although most are bound to narrow contexts.


There is no keybinding for this package (irony?). Use the command palette to execute the command search-all-keybindings:open. When the binding data is finished loading then input a key combination in the search box and press enter.

Examples: ctrl-shift-x, shift-ctrl-X, ctrl-k right, J, g >

A list of matching key bindings will be shown. The rows are ordered with the most downloaded packages first. Each row has:

  • Number of downloads of the package
  • The command, e.g. find-and-replace:open
  • The keypress, e.g ctrl-F
  • The scope for the binding, e.g .workspace .editor


search-all-keybindings is copyright Mark Hahn by the MIT license.


I appreciate the effort. Frankly I agree with @leedohm, that package author should be very careful about adding key binding to their package. This might be a good start.


Sometimes you have to have a keybinding. That might be the whole purpose. It has been proposed that the user should always have to add the binding but if you think about it the user can already do that.

Unfortunately search-all-keybindings is not popular. It only has 24 downloads after more than a month. I use it every time I need a binding of course.


Well I guess some defaults for packages might be nice in some cases. For example if there are some packages which are copies of existing packages from Sublime, for user it would be nice to use same shortcuts right from the start. What I don’t like is the fact that package can overwrite existing keybinding without user knowing about it.


In another topic, I made the suggestion that packages could put their standard keybindings in a separate package. So you would install foo for the functionality and foo-keybindings if you wanted the standard keybindings for the package.


I wouldn’t take it too personally, they’re aren’t that many package developers yet :smile:

Also, useful for a one off hot key binding…

I haven’t had to use it yet, but I know I will heh.


Maybe we should make a conflict alerter @ install time? You get to pick which one wins or an alternate (if you prefer neither of the 2 conflicting keys)


@leedohm so does that mean , that I user would have to check if there are any conflicts? If yes what he would have to do , download key biding package and change key biding afterwards?

I like what @DavidLGoldberg proposed. In that case only keybiding in conflicts would show up and you can set which one to use.


@Trudko, they would have the choice of either taking what the package owner considers “the defaults” or making their own key bindings … or something in between. The way things work now, they either get nothing or they get the defaults, there is no choice for the user.

Here is the post I made that describes the general problem:


Now this is something I can get behind. It just means the package keybindings are always optional.

Wait. Doesn’t overriding existing defaults take exactly the same amount of work as clicking on option to disable and then adding your custom bindings?

Wait wait. If there are some bindings you don’t want at all then this saves the effort of putting in !ignore bindings.

I’ll put this on my list of packages to develop.