You’ll want to know all the commands available to you. Open the Settings panel (cmd-,) and select the Keybindings tab. It will show you all the keybindings currently in use.
It acknowledges that we’ll want to know all the commands available to us, but then instead tells us all the keybindings available to us, which is a very different thing. If I knew all of the commands available, I could easily create new keybindings, but just knowing all existing keybindings doesn’t really help me to do that.
To give a concrete example of what I could do with such a list—I could add a working keybinding for inserting a tab character.
# Sometimes it's useful to be able to insert a literal tab character
'.editor':
'ctrl-alt-tab': 'editor:tab' # <---- non-working pseudo-code
Without the list, I’m not sure how to insert a literal tab. I can insert a newline (editor:newline) but not a tab.
There are hundreds of other things that I might want to bind to keys, but without a comprehensive list, or a way to get Atom to generate such a list, I don’t know of any way to find them out.
As @muchweb stated, the full list of commands is in the Command Palette. On the other hand, it is possible to assign a keybinding to any command in the Command Palette. That said, there may be functionality in Atom or packages that is not exposed via a command … at which point, you cannot assign a keybinding to it.
To sum up:
If there is a command for it, it is in the Command Palette
If there is a command for it, you can assign a keybinding to it (and the Keybindings page in Settings is one way to determine that mapping)
Just because Atom or a package can do it, doesn’t mean there’s a command attached to it
Been looking for the answer to this myself. If you open a console and type atom.commands.registeredCommands it will shows a complete list of all available command identifiers. Or at least I think that’s all of them. : )
That’s not totally accurate, only commands available from the current context appears in the command palette.
By context I mean the DOM element that currently have the focus. For instance, if you place the focus in an editor, the command palette will display every commands that you can trigger from here, which includes global commands (registered on atom-workspace) and editor’s commands (registered on atom-text-editor).
Now, place the focus on the tree view and the editor’s commands will no longer appear in the command palette.
As for keybindings it’s a little more subtle, you can register keybindings even if the command it targets doesn’t exist. Keybinding are just a way to tell Atom to trigger a command from a given context (through the keymap selector), so on the corresponding keystroke it’ll look at a command with the same name and with a selector that matches the current focused element.
If I click on a directory in the tree view to give it the focus (clicking on a file will open an editor and put the focus in it) and open the palette command the foo command will be displayed with its keybinding. If I focus the editor, the foo command no longer appears in the command palette.
Now, about the keybindings view in the settings panel, it displays every registered keybinding, but that doesn’t mean there’s a corresponding command. In the example above, if I omit to define the foo command, the keybinding for foo will still appear in the settings.
In that, the documentation is somehow misleading because the settings view won’t show you commands that aren’t bound to a keybinding, but it will show you orphan keybindings. So you can’t rely on it to know the available commands, only the available keybindings.
Now, to list every commands registered in Atom it gets more complicated.
As mentionned by @leedohm, registeredCommands isn’t a confirmed public API, neither is selectorBasedListenersByCommandName.
The problem with registeredCommands is that it’ll only tell you that there’s a command with this name available somewhere, but it won’t tell you how you can trigger it. So it doesn’t help if the goal is to attach a keybinding to that command. selectorBasedListenersByCommandName is much more accurate as it references the selectors in which a given command applies. But you can have several selectors for a single command with very different implementations depending on the scope where it applies (like core:move-up command).
The “context” is a CSS selector as described in the Atom Flight Manual section Keymaps In-Depth. Because it is a CSS selector, an exhaustive list would be pointless (if not infinitely long). The majority of keybindings should either be bound to atom-text-editor (for when it applies to both code editor views and simple single-line entry fields), atom-workspace (for things that should work anywhere such as Cmd+S) or atom-text-editor:not([mini]) (for things that should only work inside a code editor).
I’ve been trying to find a command name, and found a few threads on here but no real answers. (I also tried the command palette, and found the item, but not the name. Currently hovering doesn’t seem to reveal the command name.)
I searched atom’s repo on github to find the source .cson. This is probably really silly but it did eventually work out for me. So if you really, really want a keyboard shortcut to save with whitespace or whatever silly menu item, it’s definitely buried in the source somewhere
The command is just the displayed name but lowercased and dasherized in more than 99% of cases. It wasn’t until very recently that the display name can be changed to be different from the command.
yup. nice. no harm in just trying this first. works pretty much every time.
So Packages > Whitespace > Remove Trailing Whitespace is just whitespace:remove-trailing-whitespace.
