Cmd/Ctrl K "open edit" conflicts with "open composer" after import from VSCode with user defined Cmd/Ctrl K combinations

Below is written with screenshots on PC, but both PC and Mac have the same issue.

Steps to reproduce:

  1. In VSCode, create any user defined keybinding leading with ctrl k, for instance:
   {
    "key": "ctrl+k ctrl+n",
    "command": "workbench.action.newWindow"
   }
  1. In Cursor, import settings from VSCode.

  2. Cursor will try to convert all VSCode keybindings leading with ctrl k to ctrl m (or cmd r on Mac), for the goal of freeing up ctrl 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)

  3. After import, based on some fallback algorithm, ctrl k for “edit” will fall back to ctrl shift k.

  4. However, ctrl shift k is already “open composer”

  5. As a result, when I select some code then press ctrl shift k, the “edit” popup doesn’t show, instead the composer opens.

  6. 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)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.