alt-gr meta key not available?

[snowiow]

From what I've seen in the docs it looks like that the alt-gr meta key can't be mapped for keybindings in the package.json for a plugin. Will this be supported in the future or is there any other way? Thanks in advance.

[guillermooo]

#713

[alexdima]

pressing AltGr+X in all OSes results in Ctrl+Alt+X where X is a key code. So to map AltGr+P for example you would map Ctrl+Alt+P

[snowiow]

Doesn't work for me. I tried to map the open curly to alt-gr-7. Following your tip, I mapped it to Ctrl+Alt+7, which is working, if I press that combination. But if I press alt-gr+7, it still writes 7

[alexdima]

@snowiow I'm not sure I understand the problem? Can you please share the keybinding rule or your use-case?

[snowiow]

Sure I Have got something like this in the plugin's package.json

"keybindings": {
    { "key": "Ctrl+Alt+7", "command": "extension.v_{", "when": "editorTextFocus" }
}

Then in the extension.ts I register this command to a handler method

export function activate(context: vscode.ExtensionContext) {
    ....
    registerCommand(context, 'extension.v_7', () => handle("7"));
    registerCommand(context, 'extension.v_{', () => handle("{"));
    ....
}

function handle(key:string) {
    console.log(key); //Prints "{" on Ctrl+Alt+7 and "7" on alt-gr+7
}

[alexdima]

@snowiow Thank you for clarifying. I know this is currently the only way to do anything with keys from an extension, but the keybindings rules are a pretty bad way to do character input. The reason is that the keybinding rules are interpreted on browser event keydown where we're only receiving key codes and not characters. (See #713 for an explanation of how you cannot really support different keyboard layouts going with the keybindings approach).

Also, you might have noticed that we do not bind by default any keybindings that produce characters. (e.g. no key binding for pressing a, shift+a, b, etc.). That is because the keyboard dispatcher interpretes the pressed keys and if a key has no rule, then we do not call preventDefault() on the keydown event. Then, browsers will do their thing, and they will follow up with keypress and input events. We don't even use that to figure out the character input, since the properties in a keypress are inconsistent across browsers and they wouldn't help in the CJK case. Instead, we install a timeout and then we look inside our textarea input and check it's .value to figure out what was typed. We then take that value and call an internal type handler.

I have digged into Chromium sources last week and not even Chromium knows reliably what character would be produced on a keydown on all the platforms it supports. Chromium itself also reacts to the OS events and I think some OSes do not always give the produced characters. Also, there is the composition case for e.g. CJK characters.

I have an item on the plan (#917) to understand how VIM extensions could be implemented better:

• API: Investigate into how we can provide more support for the VIM extensions
  • Issues: Vim control mode #300, keybindings should not work in normal mode by default #575, Expose methods to alter cursor appearance via extensions API #561,

I think at least in part, supporting VIM extensions consists of providing a means to redirect the character input and instead of calling the internal type handler, to be able to call a command on an extension or perhaps toggle between the two.

[alexdima]

@snowiow @guillermooo Thank you for your patience with this.

Please see https://github.com/alexandrudima/vscode-vim if you are authoring a vim emulation extension for VS Code - it is a sample that shows how to capture typed characters (not through keybinding rules).