can't override the default key binding

[LeonardoGentile]

I want to change the cmd-[ and cmd-] key bindings for switching tabs so I've added this to my keymap.cson

'body':
  'cmd-]': 'pane:show-next-item'
  'cmd-[': 'pane:show-previous-item'

but no matter what when I press them I get the default behaviour (indentation/outdentation).

Should't the custom settings take precedence over the default ones?

[kevinsawicki]

Can you try using the .workspace, .workspace .editor:not(.mini) selector instead of `body?

[LeonardoGentile]

You mean like this?

'.workspace, .workspace .editor:not(.mini)':
  'cmd-]': 'pane:show-next-item'
  'cmd-[': 'pane:show-previous-item'

it did not produce any difference.
I'm wondering if could be the keyboard. I'm using a non-US keyboard but I chose a US layout...

[nathansobo]

Would be interesting to see a similar screenshot to the one above from the settings view with that binding loaded. Also, could you try using the Keybinding Resolver available via the command palette to see what is getting recognized when you hit that key?

[LeonardoGentile]

Here we go. This is the screenshot of the settings view after applying the changes

I have a new clue. The keybindings actually DO work as they are supposed to do (switching tab) ONLY if I am in the settings panel. That means that if I am on the settings panel and I hit cmd-[ I go to the previous tab BUT if I am on a normal editor tab and I hit again cmd-[ I get outdentation. The same is equivalent for cmd-[.

This screenshot is of the keys being hit when I am on the settings panel (working)

And this one is when I do the same but on a normal editor

[izuzak]

@LeonardoGentile Sorry for the delay in getting back to you!

You should be able to remove the outdentation keybinding using the unset! directive.

Still, this is an interesting question: in case a keystroke (cmd-[ n this case) is bound in two keybindings that have exactly the same selector (.workspace .editor:not(.mini) in this case), but one of those is a keybinding defined in keymap.cson -- should that keybinding take precedence over the other? It seems that users might expect this behavior. /cc @nathansobo

[izuzak]

After looking into this a bit more, I don't think this is related to preferring keybindings defined in keymap.cson over other keybindings (as far as I understand, this is already how things work because the keybindings from keymap.cson are added last).

I believe we're just getting trolled by how specificity is calculated for selector groups. I've opened atom/atom-keymap#33 for discussion, but the tl;dr is: the order of selectors in selector groups affects the specificity, and therefore the matching.

So, @LeonardoGentile, try using .workspace .editor:not(.mini), .workspace instead of .workspace, .workspace .editor:not(.mini) (notice the different order). Or, use two separate selectors, like this:

'.workspace':
  'cmd-]': 'pane:show-next-item'
  'cmd-[': 'pane:show-previous-item'

'.workspace .editor:not(.mini)':
  'cmd-]': 'pane:show-next-item'
  'cmd-[': 'pane:show-previous-item'

Hope that helps. Also, closing this in favor of atom/atom-keymap#33.

[joel-regen]

so...um... is there any way to just make this a little more user friendly? Like how eclipse works?

[NoahDavidATL]

Ditto. I'm having the worst fucking time associating "cmd-d" with duplicate lines and "cmd-e" with delete lines. I put the override commands in keymap.cson and they just don't work.

[TakanashiOuken]

Having the same issue
'body':
'ctrl-tab': 'pane:show-next-item'
'ctrl-shift-tab': 'pane:show-previous-item'
Does not seem to work

[emlazzarin]

I'm also having the problem TakanashiOuken is having.

[TakanashiOuken]

'body':
"ctrl-alt-tab": "pane:show-next-item"
"ctrl-alt-shift-tab": "pane:show-previous-item"
I did this at the end...

[iamsellek]

@TakanashiOuken @emlazzarin

Just figured out the issue. If you do a search in the keybindings section for 'ctrl-tab', you'll see that there's this 'ctrl-tab ^ctrl' shortcut as well:

That one is the one taking precedence for the 'ctrl-tab' shortcut. To fix, just add an !unset for that one, too. To get browser-like tab navigation working, just do the following:

'body':
'ctrl-tab': 'unset!'
'ctrl-shift-tab': 'unset!'
'ctrl-tab ^ctrl': 'unset!'
'ctrl-shift-tab ^ctrl': 'unset!'
'ctrl-tab': 'pane:show-next-item'
'ctrl-shift-tab': 'pane:show-previous-item'

[ghost]

@iamsellek please add your respose to docs and save people from googling

[guyca]

time_spent_here += 2;
@iamsellek Thanks a lot!

[ghost]

Had this problem with platformio-ide-terminal plugin
ctrl-enter (run selection) was overwritten by enter(new line) even after modyfying the specificity to the same "enter" has
atom-workspace atom-text-editor:not([mini])
the unset! method worked but i could no longer make new lines, a bit annoying...
Finally @izuzak 's adding of , .worspace did it! :

I'll try to report this to platformio-ide-terminal people, anyway thank you

[rizrmd]

All of above suggestion failed for me, then I did this:

'body':
  'ctrl-tab ^ctrl': 'unset!'
  'ctrl-shift-tab ^ctrl': 'unset!'
  'ctrl-shift-tab': 'pane:show-previous-item'
  'ctrl-tab': 'pane:show-next-item'

It works

[iamsellek]

@rizkyramadhan That seems to be the latest fix, after an Atom update at some point!