Keybindings clash

[tass6773]

I am having an issues with All All Commit Push taking about 40 seconds before the comment section comes up. It took another 10 seconds to save the comments, and another 30 seconds before the push was complete. Doing all 3 from the command line takes less than 5 seconds. How do I go about debugging to see if there is an issues? Is there a log file I can view?

[stared]

I am also experiencing the same problem (on OS X El Capitan).

Adding a file takes ~5 sec, opening commit message - another 5 sec and saving it - 5 sec or so. In the command line it is instantaneous.

EDIT: After upgrading Atom to 1.6.0 (and perhaps other changes with other libraries) there is no delay.

[chrisduong]

I'm having the same issue, for e.g., to let 'git-plus' make a commit (shift-cmd-C), I have to type (shift-cmd-H) to make the previous commit take action.

[chrisduong]

another hack is to move to next tab, but the next tab get staged not the current tab that I have staged

[bjonica]

Adding to that, doing a Git Add also seems to take 30+ seconds -- but I can speed it up by saving a file (at which point the saved file gets added, which is not necessary the file or version of the file I intended to add).

This previously worked very well.

EDIT: I was able to narrow it down a bit -- I don't have an issue when I run git functions using the command pallette, but I do when I use the default keyboard shortcuts

[bjonica]

I was able to resolve my issue by removing the default partially-conflicting keybindings that delayed execution until another character was typed. For example, shift-cmd-A a for Git Add All is like shift-cmd-A for Git Add, but with a delay waiting on another a. After getting rid of these, Git Add is very fast again. Consider taking a look at keybindings, possibly from other plugins, and see if there is a shared root binding. In any case, the fact that this delays execution by several seconds is a bug, but I'm not sure if it is the same bug the rest of you are seeing.

[chrisduong]

Hi,

I've checked all my key bindings there is no confliction, so I don't think key bindings causing it.

[dimfeld]

The issue @bjonica described occurs with the default key bindings for Git Plus. It's not an issue of two commands with the same key binding, but of Atom waiting too long to figure out if you're typing a binding with a prefix when the prefix is also a command on its own. See the git-plus:add and git-plus:status bindings, for example. If you open the keybinding resolve window (cmd-. on Mac) you can see Atom waiting for the second key when you press shift-cmd-A if you have all the default keybindings enabled.

FWIW my workaround was the same, to remove the default key bindings and define only the ones I care about while avoiding prefix bindings.

[akonwi]

I'm sorry I'm late to the discussion on this.

@dimfeld Thanks for the explanation and for opening an issue in the atom repo.

I think the workaround is the best solution right now. I'd like to remove the bindings defined in the package and leave the onus on users since the commands are all exposed anyway.

Are there any objections or other solutions?

[albertosantini]

About notification (#419) I gave another try with Atom 1.12.2.

It seems it works ok.

[akonwi]

I think I'm going to remove the default bindings from the package soon so users can define their own and take the responsibility of clashing keybindings off the package

[elliotaplant]

This seems like a reasonable solution to the problem at hand. Could we update the README.md file's Default key binding column? Or maybe remove it altogether?

If this seems like a good idea I'll raise an issue and make a PR tonight.

[akonwi]

That is a great idea @elliotaplant. I forgot about that in the readme. Thanks!

[elliotaplant]

The PR is up and awaiting approval!