Word navigation keybindings conflict with the new "Smart Selection" feature

[ZaLiTHkA]

Note: This comes from the outcome of a bug report I opened in the main VSCode repo.

Looking through the keybindinds added by this extension, there are two that conflict with the recently added "Smart Selection" feature:

• Alt + Shift + LeftArrow conflicts with editor.action.smartSelect.shrink
• Alt + Shift + RightArrow conflicts with editor.action.smartSelect.expand

With that said, it has been a while since I used ST3, but I don't remember those specific keyboard shortcuts working to select the previous/next words, I always used Ctrl + Shift + Left/Right for that.

In light of this, I propose these custom bindings be removed from this extension.

[ZaLiTHkA]

Moving the second part of my ticket description to a comment instead:

On the note of keyboard shortcuts, there was actually something similar to VSCode's new "Smart Selection", but not quite as powerful or flexible. ST3 has a shortcut of Ctrl + Shift + M that would select the contents of the immediate parent braces (applying to [ ], { } and ( )). Which grew out of the Ctrl + M shortcut that would move to cursor to the current parent braces "opening" and then "closing" brace.

I know the Ctrl + M shortcut was added to this extension, but the Ctrl + Shift + M was not. So perhaps there's room for a bit of "similar feature" improvements here?

Although, I can't find any editor actions in the "Keyboard Shortcuts" list that actually do that in VSCode, so this extra tweak may not actually be possible after all..

[ZaLiTHkA]

Just a quick note: I no longer use this plugin now (mostly because of these shortcut conflicts), so I won't be adding more info to this task as I won't know of any new conflicts that come up.

That said, I'm still more than happy to help test this if any changes are made relating to this.

[yisibl]

So I understand that this problem requires support Ctrl + Shift + M, right?

[ZaLiTHkA]

So I understand that this problem requires support Ctrl + Shift + M, right?

the problem itself is that simply adding custom shortcuts to mimic ST3 behaviour isn't sufficient. the standard VSCode shortcuts that conflict with the ST3 shortcuts should actually be overridden as well.

otherwise you end up with the scenario I described in my first post, where the custom shortcuts assigned by this extension conflict with shortcuts that are already configured as "default" in VSCode.

my note on the Ctrl + Shift + M shortcut was literally just an afterthought of "I noticed it wasn't added".