Settings-view: 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 :trollface: by how specificity is calculated for selector groups. I've opened https://github.com/atom/atom-keymap/issues/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 https://github.com/atom/atom-keymap/issues/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

[rizkyramadhan]

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!