See the tail end of atom/vim-mode#129 for context.

See atom+dvorak discussion in the forums.

For developers who type with the Dvorak keyboard layout, universal shortcuts like Cmd+C require two hands, which wastes time. As a result, most OS X users who type with Dvorak use the operating system's built-in "Dvorak Qwerty" mode, which automatically reverts to Qwerty when keys like Cmd or Ctrl are pressed, so that we can use the same hotkeys as everyone else.

Unfortunately, this doesn't seem to work in Atom – with Cmd pressed, the keys still map to their Dvorak equivalents. This is a common problem in Java-based IDEs (Eclipse, Netbeans, PHPStorm, ... ) and is one reason I've stuck with Sublime Text – which does not have this issue – for so long. Interestingly, I have never found an application in the App Store with the problem, so I would assume it has something to do with how key events are read from the operating system (Atom should not, in theory, need to know anything about my chosen keyboard layout).

You can try this mode on any Mac:

The only workaround I know of would be for me to manually override every hotkey of every plugin, which isn't really up there on my bucket list. I'd be happy to help implement a fix or test this, but at the moment I really don't know where to start.

Thanks!

I installed atom-keymap in a test app using apm (apm 0.51.0 - npm 1.4.4 - node 0.10.26) - when I then try to run the test app using atom-shell (which says it is using node.js v0.11.10 and atom-shell 0.12.3.) I get the exception at the bottom. I tried many different things to get it to work, but nothing did it for me.. Is this a known problem?

ReferenceError: Set is not defined
    at Object.<anonymous> (/Users/username/app/node_modules/atom-keymap/lib/helpers.js:8:23)
    at Object.<anonymous> (/Users/username/app/node_modules/atom-keymap/lib/helpers.js:275:4)
    at Module._compile (module.js:455:26)
    at Object.Module._extensions..js (module.js:473:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:311:12)
    at Module.require (module.js:363:17)
    at require (module.js:379:17)
    at Object.<anonymous> (/Users/username/app/node_modules/atom-keymap/lib/key-binding.js:6:26)
    at Object.<anonymous> (/Users/username/app/node_modules/atom-keymap/lib/key-binding.js:57:4)

For some releases now the keybinding Ctrl+Shift+7 in a qwerty pt_PT (no dead keys) layout is not working correctly.

Operating System: Ubuntu 14.04

Expected key: Ctrl+/
Real Keybinding: Ctrl+?

(when using Ctrl+. to debug)

Bottom line, I think it is mapped to the wrong key.

Suppose I define the following in my keymap.json file:

'atom-text-editor:not(mini).autocomplete-active':
  'tab': 'unset!'
  'enter': 'autocomplete-plus:confirm'
  'up': 'unset!'
  'down': 'unset!'
  'ctrl-p': 'autocomplete-plus:select-previous'
  'ctrl-n': 'autocomplete-plus:select-next'

And then I decide that I don't want to do that, so I comment it all out:

# 'atom-text-editor:not(mini).autocomplete-active':
#   'tab': 'unset!'
#   'enter': 'autocomplete-plus:confirm'
#   'up': 'unset!'
#   'down': 'unset!'
#   'ctrl-p': 'autocomplete-plus:select-previous'
#   'ctrl-n': 'autocomplete-plus:select-next'

If I have no other cson content, then I believe (according to

I.e. If i only have one definition in my keymap and I wish to unset it by commenting it out, I have to quit and relaunch Atom.

If a keymap file cannot be loaded, atom should still invalidate any prior keymap associated with that file.

When i press ":" the first time nothing happens. But when I type it one more time the ":'" appears.

Note: I do not use a default US layout. To Type characters like {}():;<>[] I use the capslock key plus a normal letter. All those mappings work fine with atom, except of the ":" which is mapped to Capslok + g (g = key code 0x29)

As discussed here: http://discuss.atom.io/t/ctrl-k-as-prefix-key-linux/9553

This simple example causes this bug and is only tested on Linux (0.96.0-7410f9a).

'.workspace .editor:not(.mini)':
  'ctrl-u': 'editor:move-to-beginning-of-line'
  'ctrl-u j': 'editor:move-to-end-of-line'
  'ctrl-u j': 'unset!'

Here Ctrl-u waits for Ctrl-u j to happen although it's unset. Ctrl-u j does nothing as intended, but the prefix key still waits for it to trigger.

Hitting Ctrl-u here should not cause a delay.

So I wanted to change my hotkeys so it doesn't conflict with typing [ by changing the win32.json. (like here)
Which worked the first time I did it. Then somehow I couldn't type [ anymore so I tried it again. The entry "ctrl-alt-]": "editor:unfold-current-row", reappeared in the win32.json file. I removed it.

Now when I try to open Atom I am greeted by this screen instead of the usual Atom editor.

Clicking on the link on the bottom highlights the selected part.

I checked the index.js but don't see anything wrong. I immediately looked at win32.json since that is the file that I changed but also don't see anything wrong. I let it run through a JSON verifyer which also doesn't mention any problems.
I also looked at cson.js, which looks fine to me. I never modified cson.js.
Here's a gist of the mentioned files.

If anyone knows what file to fix or how to solve this problem, your help is very appreciated.
Thanks!

See related Discuss thread: http://discuss.atom.io/t/toggle-soft-wrap-key-binding/2643/3?u=leedohm

Repro Steps

1. Launch Atom
2. Open Keybinding Resolver Cmd+.
3. Hold down the Command and Alt keys
4. Observe that the Keybinding Resolver shows alt-cmd as expected
5. While continuing to hold down the Command and Alt keys, press the backslash key </kbd>

Expected: Keybinding Resolver shows alt-cmd-\ like when it displays any other key chord, even if it is not tied to a command
Actual: Keybinding Resolver shows cmd

Currently it is not possible to override keybindings, instead you add additional keybindings for a package's keybindings in your own keymap definitions.

For example:
It is a really pain when you are using Git-Diff with the Swiss-German (French, etc) keyboard layout because "alt-g" is mapped to "@". The issue is that you always have to type "alt-g" twice to get the "@" and this is not really usable IMHO: atom/git-diff#15

I'm not sure whether this is a bug or a limitation of shadom DOM but I can't find a way to trigger a command on an element in a shadow root.

Here's my use case: I have a custom element to edit a table, which use a shadow DOM for its content, I also have an atom-text-editor element used for editing the cell's content that is contained inside the shadow root (seems like the only way to make it render properly). I would like to remap some editor's commands to make it feel more natural for users (the editor is multiline but enter should trigger a confirmation, and ctrl-enter a new line insertion for instance).
It turns out that using the following keymap doesn't trigger the expected command on the text editor element:

'atom-table-editor::shadow atom-text-editor':
  'enter': 'core:confirm'
  'ctrl-enter': 'editor:newline'

Is there a way to workaround this issue?
Is it something that can be workaround?

I haven't looked at the keymap implementation in detail, but if it use the matches method I can say that it doesn't reach nodes inside a shadow root.

Here's a sample of a test in the console that demonstrates that matches doesn't work with shadow root:

> e = atom.views.getView(atom.workspace.getActiveTextEditor())
<atom-text-editor class=​"editor" tabindex=​"-1" callattachhooks=​"true" data-grammar=​"source coffee" data-encoding=​"utf8">​…​</atom-text-editor>​
> g = e.shadowRoot.querySelector('.indent-guide')
<span class=​"leading-whitespace indent-guide invisible-character">​··​</span>​
> g.matches('atom-text-editor::shadow .indent-guide')
false
> g.matches('.indent-guide')
true

What approach would you consider for this use case?

FWIW the code of the original space-pen version can be found here: https://github.com/abe33/atom-table-edit/blob/master/lib/table-view.coffee#L761-L777
And the WIP version using custom element is there: https://github.com/abe33/atom-table-edit/blob/master/lib/table-view.coffee#L761-L777

If the active element is an Editor View, keys bound to .editor will be chosen over the those bound to .workspace .pane even though .workspace .pane has a higher specificity and

Either I'm blind or there is no keybind to unindent a line in Atom like there is in for example Sublime. Would be nice if that could be added :)

Use case: two commands share the same keybinding so I want to define my own keymap for one of the commands to resolve the conflict. Right now doing so results in two keymaps for the command: the custom one that I have defined as well as the one that conflicts.

1. Using Atom Version 0.79.0 (0.79.0)
2. I set my settings like this:
   
   Where mission control activates with control+up
3. Keyboard shortcut for Add Selection Above in Atom is control+shift+up.
4. Expected behavior: Atom's shortcut takes precedence
   What I got: mission control activates and plays in slow motion (when you hold shift + some native animation it plays in slow motion).
5. Note: Keybinding resolver reads: ctrl-shift-shift when it should read ctrl-shift-up

There might not be a way around this. The solution I came up with was just to change the binding for mission control to f4, as I do not use it much anyway.

Ref: atom/markdown-preview#114

I was experimenting with my keybindings to unmap the default Markdown Preview key:

'atom-workspace, atom-workspace atom-text-editor':
  'ctrl-shift-M': 'markdown-preview:toggle'

and set a new, grammar-scoped key:

'atom-text-editor[data-grammar="source gfm"]':
  'ctrl-shift-M': 'markdown-preview:toggle'

So I added the following to my keymap.cson:

'atom-workspace, atom-workspace atom-text-editor':
  'ctrl-shift-M': 'unset!'
'atom-text-editor[data-grammar="source gfm"]':
  'ctrl-shift-m': 'markdown-preview:toggle'

which, in theory, should make it so that Ctrl+Shift+M should only activate the Markdown Preview when a GFM text editor is focused. But if I do the following:

1. With the keymap modification above active, open a Markdown file
2. Focus the tree view
3. Press Ctrl+Shift+M

Expected: Markdown Preview is not displayed
Actual: Markdown Preview is displayed

Here's what I see in the Keybinding Resolver:

(This issue is derived from atom/settings-view#124.)

The keymap package determines which keystroke will be matched in the following way:

To match a keystroke sequence, the keymap starts at the target element for the keyboard event. It looks for key bindings associated with selectors that match the target element. If multiple match, the most specific is selected. If there is a tie in specificity, the most recently added binding wins.

However, selectors which use selector grouping (multiple selectors separated with a ,) might cause confusion due to the way specificity is calculated. Specificity is calculated based on the first selector in the group:

{specificity} = require 'clear-cut'

specificity('.workspace, .workspace .editor:not(.mini)') # 10
specificity('.workspace .editor:not(.mini), .workspace') # 30

For this reason, the order of selectors in the group plays an important role when matching keystrokes.

In order to prevent users from getting trolled by this, it might be helpful to treat selectors which use selector grouping in a special way (currently, all selectors are treated equally).

An option that comes to mind is to detect selector groups, and split such keybindings into multiple keybindings, one for each selector in the group. For example, a keybinding which binds cmd-[ to .workspace .editor:not(.mini), .workspace would be split into two keybindings:

• cmd-[ bound to .workspace (specificity 10)
• cmd-[ bound to .workspace .editor:not(.mini) (specificity 30)

As a result, in elements matched by .workspace .editor:not(.mini), the specificity used for cmd-[ would be 30, and not 10 (which what is being used now).

cc @nathansobo @kevinsawicki

I use Mac's Dvorak - Qwerty ⌘ mode for my keyboard layout. Recently, Atom gained full support for this keyboard layout (yay!), but I found one shortcut not working...

When I try to comment something out in a CSS or JS file by using the ⌘ + / shortcut, nothing happens. All other shortcuts that I use work, including copy, paste, command palette, find, etc. All of them use the ⌘ key and they work.

I tried to disable my 3rd party packages, but it still didn't work.

I checked my keybindings, and commenting is indeed set to ⌘ + /.

I have no custom keybindings.

Changing my keyboard layout to US allows me to use the shortcut, so I know is has something to do with the Dvorak - Qwerty ⌘ mode.

Yosemite 10.10
Atom 0.145.0

Mac OS X 10.9.2

Ctrl-k is mapped to editor:cut-to-end-of-line, which works correctly, but performing Ctrl-k multiple times leads to only the last line killed to be stored in the clipboard.

Ctrl-y isn't mapped to anything, but emacs users would expect it to be default mapped paste.

Using 0.139.0 on macos. When i do cmd+/ in the key binding resolver.
The command is not shown as it does for other keys.

I'm using french canadian layout

I would love to bind some actions on the windows key, but apparently, it does not resolve right now.

Key Binding Resolver will show "win" when i press the windows key, but once it Try something like win-A, it will display just "a".

c:\Users\Michael J. Calkins\AppData\Local\atom\app-0.166.0\resources\app\node_modules\text-buffer\lib\text-buffer.js:387
Hide Stack Trace
TypeError: Cannot read property 'length' of undefined
  at TextBuffer.module.exports.TextBuffer.lineLengthForRow (c:\Users\Michael J. Calkins\AppData\Local\atom\app-0.166.0\resources\app\node_modules\text-buffer\lib\text-buffer.js:387:29)
  at TextBuffer.module.exports.TextBuffer.clipPosition (c:\Users\Michael J. Calkins\AppData\Local\atom\app-0.166.0\resources\app\node_modules\text-buffer\lib\text-buffer.js:939:53)
  at DisplayBuffer.module.exports.DisplayBuffer.screenPositionForBufferPosition (c:\Users\Michael J. Calkins\AppData\Local\atom\app-0.166.0\resources\app\src\display-buffer.js:1009:27)
  at DisplayBuffer.module.exports.DisplayBuffer.scrollToBufferPosition (c:\Users\Michael J. Calkins\AppData\Local\atom\app-0.166.0\resources\app\src\display-buffer.js:661:47)
  at TextEditor.module.exports.TextEditor.scrollToBufferPosition (c:\Users\Michael J. Calkins\AppData\Local\atom\app-0.166.0\resources\app\src\text-editor.js:2631:33)
  at GoToLineView.module.exports.GoToLineView.confirm (c:\Users\Michael J. Calkins\AppData\Local\atom\app-0.166.0\resources\app\node_modules\go-to-line\lib\go-to-line-view.js:116:14)
  at atom-text-editor.<anonymous> (c:\Users\Michael J. Calkins\AppData\Local\atom\app-0.166.0\resources\app\node_modules\go-to-line\lib\go-to-line-view.js:55:24)
  at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (c:\Users\Michael J. Calkins\AppData\Local\atom\app-0.166.0\resources\app\src\command-registry.js:243:29)
  at c:\Users\Michael J. Calkins\AppData\Local\atom\app-0.166.0\resources\app\src\command-registry.js:3:61
  at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (c:\Users\Michael J. Calkins\AppData\Local\atom\app-0.166.0\resources\app\node_modules\atom-keymap\lib\keymap-manager.js:549:16)
  at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (c:\Users\Michael J. Calkins\AppData\Local\atom\app-0.166.0\resources\app\node_modules\atom-keymap\lib\keymap-manager.js:391:22)
  at HTMLDocument.module.exports.WindowEventHandler.onKeydown (c:\Users\Michael J. Calkins\AppData\Local\atom\app-0.166.0\resources\app\src\window-event-handler.js:167:20)

Windows 7
I pushed Ctrl + T and then Ctrl + Shift + T can't reproduce yet.
Then the red window to create the issue came up and my editor worked fine again.

0.74 introduced the following feature:

The keymap now waits for a timeout when a keystroke sequence exactly matches one key binding and partially matches others.

While useful in some situations, it's no good for native key bindings. Here's an example:

The Swiss German keyboard features the "@" character on "alt-g". Atom uses this key binding as a shortcut to git commands e.g. "alt-g b". In order to get the "@" character back (yep, it's kinda important for coding), I've added the following to my keymap:

# Reclaim the @ character on Swiss German keyboards.
'.platform-darwin':
  'alt-g': 'native!'

This worked fine up until 0.73, but since 0.74 I have to hit "alt-g" several times to type just one "@" character. I assume it has to do with the timeout.

Suggested solution: A native key binding like "alt-g" should implicitly disable any sub-bindings like "alt-g b" and skip any timeouts.

@mcolyer wishes he had a way to do some basic globbing:

".vim-mode":
  '" [a-zA-Z]': "vim-mode:register-prefix"

This syntax would restrict the possible keys entered without needing to exhaustively listing them. If it's easier maybe it could just accept regexps here rather than trying to create a subset?

Note: This is also required for f and t motions.

I installed a package and I wanted to swap the keymapping.

When I open the command palette, the shortcut labels still show up as if the bindings are still applied

Basically, I am trying to bind alt-n to editor:move-line-down, after I save my settings, the new keybinding doesn't work(only output a letter).

Thanks

This affects keybindings like cmd-k, where cmd-k is the prefix of many keybindings that come bundled with Atom. Hitting cmd-k has a delay even if every single one of these keybindings are unset! in the user key map.

Doing some debugging, in the dev tools. What appears to be happening is this...

Putting a breakpoint on line 440 of keymap-manager.js (where partial matches are found)...

... and hitting cmd-k to hit our breakpoint, we see that the partialMatchCandidates array being filtered will iterate over the bundled keymap bindings BEFORE the user bindings. The console in the screenshot above, shows the source of all the keybindings of partialMatchCandidates. As you can all the bindings from /Application/Atom.app/* are at the top, while the user bindings from /Users/* are on the bottom. This ordering allows line 444 of keymap-manager.js to be reached, which incorrectly identifies it as a partialMatch even though a user specified keymap binding has it unset!.

A naive fix that simply reverses the order of partialMatchCandidates (process bundled bindings AFTER user bindings)...

...correctly yields an empty partialMatches as all user bindings are added to the ignoreKeystrokes set and all the bundled key bindings are then ignored.

@stmichael mentioned this behavior on a different issue #49

Similar to #9 but the solution there doesn't seem to work for me.

My keymap.cson:

'.platform-darwin .editor':
  'cmd-d': 'unset!'

'atom-text-editor:not(.mini)':
  'cmd-d': 'editor:delete-line'

There are now 3 cmd-d Keybindings, but pressing it doesn't do anything (because I unset it?). What am I supposed to do to remove the default keybinding and use it for editor:delete-line instead?

I am using arch linux with subtle as my window-manager. ctrl+c does not copy text for me, but ctrl+x works just fine.

Can you give my any tips on how to debug this further?

When using the numpad, the keyCodes do not match the ascii numbers or symbols

On my machine (windows 7)
0 - 9 have the keycodes: 96-105 where it should be 48-57
All the symbols have bad mappings as well:

The shifted variants will also need to be translated.

It appears it's pretty easy to determine when a numpad key was pressed:

if event.location is 3
   keyCode = numpadToASCII(event.keyCode)

I guess the only thing I need to know to fix this is if we want to identify these numbers/symbols separately than from the regular numbers/symbols.

I.e.

• pressing numpad 4 would result in something like 'NUM-4'
• pressing numpad . would result in 'NUM-.'

Where regular '4' and '.' would just be '4' and '.', respectively.

'.platform-darwin':
'cmd-tab': 'tree-view:toggle'

cmd-tab (under any selector), does not seem to set the command. I actually want to just unset it, because atom is getting the command and inserting an  unknown character box type thing. it does this for some other commands as well (ctrl-alt-left, for example), but those commands are not ones I use. Any workaround or hack is welcome, I just need it to stop doing this if I am going to be able to use atom.

Currently number pad keys are generated with a num- prefix to distinguish whether the key was pressed on the main keyboard or the number pad section.

This gives people more precision in their keybindings but comes at a cost, if an Atom package adds a ctrl-left keybinding and a person presses ctrl and 4 on the number pad with NumLock enabled, the key maps to ctrl-num-left and that package's command isn't triggered. People seem to be expecting number pad keys with num lock pressed to behave without distinction from their non-number pad equivalents as evidenced in atom/atom#2931

This affect any keybindings that use Home, End, PageUp, PageDown, Enter, +, -, /, *, left, right, up, and down. They all require keybindings for their command with the num- modified to target this case.

It seems like a burden on package authors to even force them to consider the number pad and num lock when coming up with keybindings.

Some options:

• Retry the keystroke without the num- modifier if no matches with the num- modifier exist.
• Remove support for the num- modified completely.
• Something else?

/cc @nathansobo and @jacobgardner

The shortcut works well when no file is open

It's hard to tell if this is by design or not, but I wanted to make a double tap of the shift key open the autocomplete menu. This approach works for doubled special keys and character literals, so I expected it to work for modifiers too.

Doesn't work:

'.editor':
  'shift shift': 'command-palette:toggle'

Does work:

'.editor':
  'escape escape': 'command-palette:toggle'

'.editor':
  'x x': 'command-palette:toggle'

(I toggled the command palette in these examples but the same applies for autocomplete, etc.)

Is this broken or by design? And if it's by design, why?

Thanks! 🐹

cmd-l seems to be hardcoded to "editor:select-line", I wanted to bind it to "go-to-line:toggle". The only way for me to override it, is to delete the binding in Atom.app/Contents/Resources/app/keymaps/darwin.json, is there a way for me to force it to unbind the default bindings?

Using the Delete key (both in the Numpad and Delete key) does not work.

Using Portuguese QWERTY Layout on Ubuntu 14.04

Originally reported here: atom/atom#2323

Aditional Information:

When using ctrl-. I'm getting:

Key Binding Resolver: .

Tracked the problem in atom to: e29185e where atom-keymap dependency was changed to 0.20 in package.json

If I revert the current value (0.21) to 0.19 and rebuild it will solve the problem temporarily until atom-keymap 0.21 is fixed.

@bhuga had an old binding with meta-r. The meta was being discarded causing the binding to match on just r. We should reject invalid bindings like this instead of letting them through.

Hi,

I'm using an ABNT2 keyboard (Brazilian)

the following is resolved wrongly:
ç -> ;
Ç -> :
" -> ~
' -> `
] ->
} -> |

I can see this in the keybind resolver ctrl+.

How can I configure my keyboard correctly? If a patch is need, I gladly would do if someone give me some pointers.

Thanks!

There's some discussion in atom/vim-mode#221 about allowing bindings based on multiple keys being smashed simultaneously. This is pretty tricky, because if we detected a keydown for a key involved in a chord, we'd need to wait for a keyup before we could be sure the chord wasn't being triggered. Not a super high priority right now, but worth implementing in the future.

There are a bunch of "ctrl-k .." bindings on Windows and Linux, but I want to bind ctrl-k to a delete-to-eol type of command (like bash or emacs). I would expect this binding to disable any prefixes. Otherwise I would have to track down every combination and set to them "unset!" or something.

Original issue: atom/atom#1625

Use https://atom.io/packages/keyboard-localization until this issue gets fixed (should be in the Blink upstream).

'body':
  'cmd-ä': 'pane:show-next-item'

'body':
  'cmd-ö': 'pane:show-previous-item'

cmd-ä is ignored while cmd-ö correctly triggers show-previous-pane. It appears ä and ö are treated as the same keys.

Atom 0.103.0, Mac OS 10.9.3.

I'm not sure if I'm doing this wrong, but I haven't been able to rebind the fn key on my Mac, so I can use fn-cmd-delete to delete to the end of a line. It seems to only delete to the beginning of the line.

It seems that #10 affects Windows as well as Linux.

ctrl-[ binding wasn't functioning in vim-mode so I stuck a console.log on the keystroke and found it wasn't correct.
Manually editing charCodeFromHexCharCode and allowing Windows to use the same fix as Linux fixed the issue.

I haven't got time to create a pr right now, but will try and do one next week if no one else gets there first.

It seems like it would make sense for Atom to be able to swap between the keys ctrl and cmd based on the OS it is running since it already knows this. This would allow one key string to match to either ctrl or cmd instead of having to specify them separately.

I'm writing a plugin that opens an iframe. The iframe requires user interaction, however, keybindings like ctrl+c, ctrl+v, ctrl+a, etc. are bubbled up and handled by Atom instead of the iframe (which has the requisite focus). Is there any way to temporarily disable handling of certain keybindings (like those aforementioned) ... or perhaps an alternative?

thanks in advance

Regarding: atom/atom#2600
@kevinsawicki

Compare US and (for example)

German keyboard layout

I think its easy to see why src/helpers.coffee is destined to fail horribly.

One example to demonstrate: I try to Toggle comments using Ctrl-/. For that I would have to press Ctrl-Shift-7 as you can see above. It registers Ctrl-?.

I don't know how, but your script somehow catches my Ctrl-Shift-7 (which would be shift+55) and makes it an ? (191) where it should make it an &.

Edit: What is that; If I press # on my keyboard it gets resolved to 3 in the keybinding resolver, but inserted correctly into the text. Something is very very wrong here! 😱

Investigating a vim-mode bug about bindings like 'i (' and 'i {' being ignored, I found the following: pressing shift alone generates a keydown event. Thus, when typing a sequence like 'i (', the 'i' gives a partial match. Then, on my keyboard, typing '(' involves pressing shift and 9 simultaneously. The shift key alone, however, generates a separate keydown event before the 9 keypress, so the partial matching gets interrupted before the actual '(' keydown event comes in. I verified this by console.logging the keydown events received on Chromium 39, Linux.

EDIT: this can be also verified by having vim-mode on, looking at the keybinding resolver. In command mode, press first 'c', then 'i'. There's the list of partial matches. As soon as I push down the shift key to type '(', the list of partial matches disappears before I could type in the actual '('.

EDIT 2: This might be Linux specific.