Keyboard interactions for Git committing

[nathansobo]

Before we staff ship, it should be possible to commit via this package without ever touching the mouse. Here's some initial thinking I did with @maxbrunsfeld on a comprehensive keybinding scheme.

• Focusing and toggling the Git and GitHub panels. These bindings are based on a logical extension of the existing binding for toggling focus on the tree view. Since they're based on numbers, we could potentially extend this scheme even further to manage other panels:
  • Existing binding
    • ctrl-0 – focus/blur the tree view
  • Proposed new bindings:
    • ctrl-shift-0 – show/hide the tree view
    • ctrl-9 – focus/blur the Git panel
    • ctrl-shift-9 – show/hide the Git panel
    • ctrl-8 – focus/blur the GitHub panel ("8" for "Octocat")
    • ctrl-shift-8 – show/hide the GitHub panel
    • esc blurs the panel, returning focus to the active pane item
• Moving focus between elements of the Git panel. When you focus the Git panel, either the unstaged/staged file list is focused or the commit message editor is focused.
  • "Sub-focus" is retained across panel focus/blur events, so you could blur the panel with the commit message editor focused, then still have the editor focused when you restore focus to the panel.
  • tab moves forward between merge conflicts, unstaged files, staged files and finally to the commit message editor. Once focus is in the editor, we do not change focus on tab but instead insert tabs / spaces into the editor. To return to the lists, use shift-tab.
  • shift-tab moves backward from the commit message editor to the staged files, unstaged files, and finally merge conflicts. To match behavior of tab going forward, we don't cycle around.
  • Intuitive arrow navigation
    • down on the last entry in the file list focuses the commit editor.
    • up at position (0, 0) of the editor moves to the last item of the file list.
• Navigating unstaged/staged files
  • up and down navigate both unstaged and staged file lists as a single list.
  • left transfers focus from the panel to the currently selected diff
  • right transfers focus to the current diff back to the panel
  • enter toggles staging status on the selected file and selects the next item in the list.
• Committing
  • cmd-enter (ctrl-enter on Win/Linux) anywhere in the git panel with a non-empty commit message creates a commit.
  • cmd-enter with an empty commit message focuses the commit editor.

/cc @atom/core

[simurai]

How about a "stage all" shortcut so you don't have to stage files one by one (still need a button for that as well).

• Navigating unstaged/staged files
  • shift-enter toggles staging status on all files in a list. Basically moves all files between unstaged/stages changes.

And maybe combined with commiting.

• Committing
  • cmd-shift-enter (ctrl-enter on Win/Linux) anywhere in the git panel with a non-empty commit message stages all files and creates a commit.
  • cmd-shift-enter with an empty commit message stages all files and focuses the commit editor.

[nathansobo]

Adjusted the specification for tab and shift-tab in the Git panel to visit each list after having second thoughts about unifying them.

[smashwilson]

I've started this off in #363, with a few minor differences from the description above:

• Merge conflicts appear between the unstaged and staged files, so the focus cycle would be (unstaged, merge conflicts, staged, commit editor) to be consistent.
• When right returns focus to the git panel from a FilePatchView, I'm thinking it should focus the corresponding entry in the file lists rather than preserving the last focus. Would that feel right to you?

[nathansobo]

Your adjustments seem very reasonable. 👍🏻

[smashwilson]

I'd like to defer two of these tasks to new PRs.

This one because I suspect it'll be much easier with #370:

• cmd-enter/ctrl-enter 👉 git:commit 👉 With an empty commit message, focuses the commit editor. With a non-empty commit message, creates a commit.

And this one because it'd muddy up the diff and collide with pretty much any other changes:

• Rename git: commands to be uniformly github: commands.

[simurai]

@smashwilson Rename git: commands to be uniformly github: commands.

Started a PR that renames all the class names: #372. Not sure if you wanna join there or start a separate one. So far I only changed the class names of the keybindings, but not the commands.

[smashwilson]

@simurai Cool, thanks! Yah, I'll do the rename on your branch 😄