Selector grouping might cause confusion because of how specificity is calculated

[izuzak]

(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

[nathansobo]

I think we should break up selectors with ,s in them into multiple selectors with duplicated contents to avoid this issue.

[wmayner]

👍 I got bitten by this