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

[ZYinMD]

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"
   }

2. In Cursor, import settings from VSCode.

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

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

   

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

   

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

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