Feature request: Add support for modifier keys like right ctrl and right alt

[beta]

Issue Type

Feature Request

Description

Currently VS Code treats left and right modifier keys as the same one (ctrl, alt and shift).

I want to define different keyboard shortcuts for left and right modifier keys (e.g. left ctrl + s for saving files, and right ctrl + s for something else), but unfortunately this cannot be done.

VS Code Info

VS Code version: Code 1.20.0 (c63189d, 2018-02-07T17:10:15.949Z)
OS version: Linux x64 4.14.16-300.fc27.x86_64

[oriash93]

possible code pointer?
https://github.com/Microsoft/vscode/blob/master/src/vs/base/common/keyCodes.ts#L21

[darsain]

Came here because I'm running out of available key combinations to use as shortcuts :) This would allow me to pretty much double it.

It's definitely possible to differentiate between them as shown here: https://w3c.github.io/uievents/tools/key-event-viewer.html

Also, add right shift and to the list! And maybe we could have NumpadEnter bindable aswell?

[momvart]

Any update on this request?
It doesn't make any conflicts with current settings and also expands possible shortcuts.
I myself usually do commands with one of the sides, and the other can be used for another shortcut.

[zepster]

Is very interesting feature request.
As example, I want to use WASD as arrows when right cmd is pressed.

[hediet]

I think this feature is almost out of scope.

However, this feature could be implemented by a separate tool, independent of VS Code.
You could use for example AutoHotkey to override keybindings on windows, so that right-ctrl + W maps to F13. Afaik you can bind to F13 in VS Code.

[ljmf00]

However, this feature could be implemented by a separate tool

The usage of an external tool to fix this issue sounds like an absolute workaround.

[darsain]

With autohotkey, you can only rebind to other keys, you can't just send a command. But what if other keys are taken? that's the main reason I want VSCode to add support for differentiating modifiers. I've run out of shortcuts to use :(

If I'd use AHK for this, I'd have to simulate multiple keypress shortcuts like ctrl+x,y, which would definitely cause issues, glitches, etc (experience from using ahk on daily basis).

And even if this was a pratical and comfortable workaround, what about other systems? ahk is windows only, and I also develop on linux, sometimes mac. Do I have to look for alternatives on each platform, and configure and maintain these setups everywhere?

The data about the key is already available on every key event, why can't vscode just use it? If I press RightCtrl+e, try to first match that, and if it doesn't have any keys bound, match Ctrl+e.

I don't understand the push back here, or the claims that this usability improvement and extending what is possible with shortcuts is out of scope. Is improving vscode not in the scope?

[hediet]

I've run out of shortcuts to use :(

You could use F13-F24, including various combinations with ctrl and shift.

[ljmf00]

I've run out of shortcuts to use :(

You could use F13-F24, including various combinations with ctrl and shift.

I don't really understand the point of mapping existing keys to possibly "virtual keys" that can be watched by the Window Manager for other custom user shortcuts. Plus, those keys actually exist on older IBM keyboards. Considering what you proposed for those who use them makes another fabricated problem, solving nothing, in practice.

[spigelli]

Would it be better to start by just allowing users to specify keycodes in the shortcuts json? Might fix some issues for international keyboards as well?

Or a distinct handleKeycodes object with either keyEvent.key:

{
  "name": "Right Alt",
  "key": "Alt",
  "Location": "2"
}

or keyEvent.code:

{
  "name": "Right Alt",
  "code":"AltRight"
}

Then the shortcuts UI could check it an entry is displayed in handleKeycodes and display the specified name when setting new shortcuts.

[ljmf00]

Would it be better to start by just allowing users to specify keycodes in the shortcuts json? Might fix some issues for international keyboards as well?

Or a distinct handleKeycodes object with either keyEvent.key:

{
  "name": "Right Alt",
  "key": "Alt",
  "Location": "2"
}

or keyEvent.code:

{
  "name": "Right Alt",
  "code":"AltRight"
}

Then the shortcuts UI could check it an entry is displayed in handleKeycodes and display the specified name when setting new shortcuts.

I believe this is also an interesting approach for custom non-standard keycodes, although I do think this is a separate feature, since Right Alt is a fairly common modifier and doesn't deserve a custom configuration, IMO.

[PEZ]

A thing to solve here is to help extension authors avoid some key bindings that would become available. For instance, I don't have a right ctrl key on my keyboard (a MacBook Pro). And since it is also a Swedish layout, I already have enough problems with some VS Code built-ins shortcut defaults.

[savetheclocktower]

I'm here because I'd love to get support for NumpadEnter as distinct from Enter. I blame TextMate for training me this way so many years ago by binding NumpadEnter — or Fn + Return on Mac laptops — to several useful sorts of commands.

It's such a convenient way of expressing “like Enter, only more so” in various contexts. Imagine using NumpadEnter

• to continue your line- or block-comment on the next line with whatever delimiter is appropriate for the file you're in, instead of the simple line break that Enter would add;
• to open the URL that your cursor is within in an HTML or Markdown file;
• to continue a Markdown list;
• and, well, these are the exact three things I use NumpadEnter for in Atom right now, but I'm sure others exist.

I could see treating Enter and NumpadEnter identically in spreadsheet software, but I can't justify an expectation that they do the same thing in an IDE. I know I'm the weird one in the room, but I think this could at least be controlled by a setting so that I could opt into the tradeoff. Or an extension hook of some sort would be great, too; Atom lets me fix this with a couple lines of code in my init file.

[eugenesvk]

It's definitely possible to differentiate between them as shown here: https://w3c.github.io/uievents/tools/key-event-viewer.html

unfortunatley afaik that's another brokey key API, it doesn't differentiate between left/right key modifiers in a combo, only when you press them as non-modifier keys, you'd need some not-fully-reliable listener/tracker of previous events (which may happen outside of your app, so you'd miss them)

[eugenesvk]

You could use F13-F24, including various combinations with ctrl and shift.

then you'd lose all the direct hints in the app and have to remember/lookup what is mapped to what.
lso external keybinding tools don't have knowledge of the app state so, e.g., if you have modal-vim-like editing plugin, they wouldn't know what mode you're in.

Also it's not x-platform unlike native support, so you'd have to duplicae work

So this approach is very unergonomic, although it beats having nothing

[mpql]

I think this feature is almost out of scope.

In what way is keyboard shortcut handling for an application that supports keyboard shortcuts remotely out of scope? Genuinely asking, because I'm not parsing the logic here. I would think this fits the stated goals of the project without need for further evaluation. The current behavior undesirably (for many) merges the assignment of multiple keys. There could very easily be a toggleable setting that determines whether these sorts of keys are merged.

You could use for example AutoHotkey to override keybindings on windows, so that right-ctrl + W maps to F13. Afaik you can bind to F13 in VS Code.

Wouldn't that also trigger the built-in Ctrl + W shortcut and close the window?

You could use F13-F24, including various combinations with ctrl and shift.

Does it seem reasonable for an application with keyboard shortcuts to support F13-F24 -- keys not on a typical keyboard -- but not support Right Ctrl, Right Shift, Right Alt, Numpad Enter, etc. -- keys generally on both full ANSI and ISO keyboards? Again, I am genuinely asking. This seems to fall firmly within the precise definition of a workaround.

[elamperti]

Requesting this reminds me a lot of this xkcd comic, but hey... I'm trying to bind my right alt key (altgr+.) to a snippet, and my xmodmap config maps that combination to » (which is what I want) but inside vscode I can't catch it neither as alt+. or ». I know I can map things to e.g. F13, and I even have a Streamdeck to play around if I need extra keys... but I just expect vscode to handle this (simple?) case. Many applications support this, and considering developers are often power users, it'd make sense to see support for this out of the box.

[ArturoDent]

You can see in keycodes.ts that the left/right modifier keys are mapped to the simple versions:

[1, ScanCode.ControlLeft, 'ControlLeft', KeyCode.Ctrl, empty, 0, 'VK_LCONTROL', empty, empty],
[1, ScanCode.ShiftLeft, 'ShiftLeft', KeyCode.Shift, empty, 0, 'VK_LSHIFT', empty, empty],
[1, ScanCode.AltLeft, 'AltLeft', KeyCode.Alt, empty, 0, 'VK_LMENU', empty, empty],
[1, ScanCode.MetaLeft, 'MetaLeft', KeyCode.Meta, empty, 0, 'VK_LWIN', empty, empty],
[1, ScanCode.ControlRight, 'ControlRight', KeyCode.Ctrl, empty, 0, 'VK_RCONTROL', empty, empty],
[1, ScanCode.ShiftRight, 'ShiftRight', KeyCode.Shift, empty, 0, 'VK_RSHIFT', empty, empty],
[1, ScanCode.AltRight, 'AltRight', KeyCode.Alt, empty, 0, 'VK_RMENU', empty, empty],
[1, ScanCode.MetaRight, 'MetaRight', KeyCode.Meta, empty, 0, 'VK_RWIN', empty, empty],

https://github.com/microsoft/vscode/blob/1cc266cc82838981034c2baa637f357a83711d5d/src/vs/base/common/keyCodes.ts#L657C1-L664C89

Why this s done I don't know.