Default keybinding problem

[EmmanuelBeziat]

Hi,

Just got the new 1.11 version, and there’s a problem on macOS:

This key combination is the actual one for doing a pipe character: |
As it’s a very common symbol in dev, this shorcut really should be changed, or it will lead the large majority of macOS users to change the default key map.

Thanks!

[chrmarti]

Which keyboard layout are you using?

[EmmanuelBeziat]

Azerty (french) Apple Keyboard — if that’s what you’re asking? Not sure, sorry.

[alexdima]

We do not ship an action called "Bookmarks (Selection): Expand Selection to Next" AFAIK. Please contact the extension that contributes this action.

[EmmanuelBeziat]

I had the extension for months, and it just happened after the VSCode update (not the extension update). There's something behind this.

Here’s a same request on the Githubs issues of the plugin: alefragnani/vscode-bookmarks#63

[alefragnani]

Hi @alexandrudima ,

I tried (really 😫 ) to digest the information from this issue you posted and the wiki section, to better understand the Improved keyboard layout support available in 1.11 release. I understand the hard work you had to improve this, on all platforms, but I missed one point: What can/must we, extension developers, do from now on?

I had a similar problem right at the beginning, because I used Ctrl + Alt on other commands. I ignored (by ignorance) the Developer Tools warning, and users from Sweden and Germany reported issues with that.

So, how can we, extension developers, avoid messing with non-US Layout while defining keybindings for extension commands? Is there a safe way to define keybindings? I mean:

• I learned (after the first reported issue) I can't use Ctrl + Alt.
• Should I avoid using Shift + Alt too (based on this issue)?
• Should I avoid keybindings at all?

Looking closer to VSCode core commands I noted that you use a lot of Ctrl, Ctrl + Shift and Ctrl + K ? (chord). Is this a safe way?

Thanks for your help

[alexdima]

@alefragnani

I am sorry about the breakage with our switching to scan code based dispatching.

We have the same problem with the core actions. i.e. it is nigh-on impossible to come up with any default that would work on all keyboard layouts and not suck or cause side-effects.

I don't have a good answer except perhaps #1240.

e.g. perhaps a way where you could specify you'd want to contribute a keybinding for ctrl+alt+L, but only on a US standard keyboard layout and have it unbound on any other keyboard layout. This is complicated by the fact that:

• sometimes we cannot even read an id for a keyboard layout (we get NULL from the OS)
• all identifiers for such keyboard layouts are different on OSX / Linux / Windows. e.g.: for the German keyboard layout: com.apple.keylayout.German on OSX, de on Linux, 1031 on Windows.
• people roll out their own custom keyboard layouts on each operating system.

[alefragnani]

@alexandrudima

You don't need to be sorry about it. I tottaly understand the complexity of this subject. And breakages, are part of evolution 👍

After the original issue, I had decided to avoid defining keybindings for new commands, on any of my extensions. I found it to be a safe way. But for this one in particular, I wanted to follow a pattern and added keybindings (using Shift) for these selection commands.

BTW, I am aware of #1240. It is already related to my original Ctrl+Alt issue 😄

Thanks again for your help