Below is written with screenshots on PC, but both PC and Mac have the same issue.
Steps to reproduce:
- In VSCode, create any user defined keybinding leading with
ctrl k
, for instance:
{
"key": "ctrl+k ctrl+n",
"command": "workbench.action.newWindow"
}
-
In Cursor, import settings from VSCode.
-
Cursor will try to convert all VSCode keybindings leading with
ctrl k
toctrl m
(orcmd r
on Mac), for the goal of freeing upctrl k
for “edit”. However, it’s unable to change the one we defined, so this goal won’t be achieved.(I didn’t test but I think extension-defined keybindings leading with
ctrl k
have the same effect, which is more common than user defined) -
After import, based on some fallback algorithm,
ctrl k
for “edit” will fall back toctrl shift k
. -
However,
ctrl shift k
is already “open composer”
-
As a result, when I select some code then press
ctrl shift k
, the “edit” popup doesn’t show, instead the composer opens. -
Notably, if I mouse click this button, it works as intended, but if I press
ctrl shift k
as it tells me to, the behavior is different from mouse click. This is a huge confusing thing on the very first minute of new user onboarding.
===================
Personally I think it’s more elegant to fallback to Ctrl 9
.
(and Ctrl l
can fallback to Ctrl 0
)