Keybindings for glist conflict with default copy and cut keys

[JPvRiel]

ctrl-c and ctrl-v behaviour on Atom 1.7.3 running on Linux stopped working after I installed glist. Disabling glist reverts back to expected behaviour.

I recognise it's possible to workaround this by disabling keybinds in the package settings and customising the packages keybinding behaviour.

However, I'm of the opinion that packages shouldn't overwrite default and expected core behaviour that a vast majority of users expect.

I can't recall if enabling key bindings is the default when the package is installed or not.

Using the keybinding resolver, when in the editor ctrl-x resolves to glist:saveGist ctrl-c resolves to a number of options that depend on the next ctrl- combination

Regardless, it 'breaks' the defaults I'd expect. I'm not very familiar with key binding scopes, but atom-workspace is very broad, suggesting that the keybinds overwrite a lot?

'atom-workspace':
  'ctrl-c ctrl-g': 'glist:toggle'
  'ctrl-x ctrl-s': 'glist:saveGist'
  'ctrl-c ctrl-d': 'glist:delete'
  'ctrl-c cmd-d': 'glist:deleteGist'
  'ctrl-c cmd-c': 'glist:copyGistUrl'
  'ctrl-c ctrl-o': 'glist:openGistWeb'

[caoyue]

I got this issue too, both on Linux and Windows. Use unset! to remove default key bindings temporarily fix this issue:

'atom-workspace':
  'ctrl-x cmd-s': 'unset!'

[theo-armour]

Newb Atom user on Windows10 here

I went to:

C:\Users%username%.atom

Opened:

keymap.cson

and added this

'atom-workspace':
  'ctrl-c ctrl-g': 'unset!'
   'ctrl-x ctrl-s': 'unset!'
   'ctrl-c ctrl-d': 'unset!'
   'ctrl-c cmd-d': 'unset!'
   'ctrl-c cmd-c': 'unset!'
   'ctrl-c ctrl-o': 'unset!'

Naughty key bindings are disabled, and I can still use Glist using a toolbar I created using command-toolbar

Thank you @JPvRiel and @caoyue for pointing me in right direction.

And a big Thank You to @jcouyang for creating a really useful package.

PS. I had been having issues with the main Atom editor scrollbar not being able to scroll from bottom of page back up to top. Now that my `glist1 key bindings have been unset, this issue seems to have gone away.

Mac, Linux and Windows users have to learn to co-exist with each other. ;-)