Terminal: Numpad shortcuts with both Ctrl and Shift don't work

Created on 1 Oct 2019 · 8Comments · Source: microsoft/terminal

Environment

Windows build number: 10.0.18362.0
Windows Terminal version (if applicable): 0.5.2681.0

Any other software? No

Steps to reproduce

Set the newTabProfile0 shortcut to "Ctrl+numpad_1" and save:

{
    "command" : "newTabProfile0",
    "keys" : 
    [
        "ctrl+numpad_1"
    ]
},

Test the shortcut to verify that it works as expected (a new terminal tab opens as expected, regardless of which shell was currently active before).

Reopen settings; change this shortcut to "ctrl+shift+numpad_1" and save. Try to use shortcut.

Expected behavior

A new terminal tab to be opened with the appropriate profile:

Actual behavior

Depends on the currently active shell. If it's Powershell or cmd, nothing. If it's Bash WSL, ";5F" appears following the prompt:

(Found this issue while testing https://github.com/microsoft/terminal/issues/2628; nto sure if it's also related to https://github.com/microsoft/terminal/issues/2967 or if I'm just incorrectly stating the shortcut?)

Area-Input Area-TerminalControl Help Wanted Issue-Bug Product-Terminal Resolution-By-Design

Source

rensa

All 8 comments

I should note that the default shortcuts, which use the top row numbers rather than the numpad (eg. "ctrl+shift+1", work fine, as do other shortcuts that use Ctrl and Shift, like the default "openNewTabDropdown", which is "ctrl_shift+space" 🙂

rensa on 1 Oct 2019

That's really interesting. I wonder if they come through as arrow keys?

I don't have a numpad on my keyboard, but would you mind running xxd in wsl and seeing the full sequence that it emits?

Thanks!

DHowett-MSFT on 23 Oct 2019

Sorry @DHowett, I haven't used xxd before. Are you asking me to run that command and then test typing in keyboard shortcuts like Ctrl+shift+_numpad1 and observing the output emitted when I type them? Just running it on its own seems to leave it waiting until I kill it.

I might not be fuly test this until next week, as I'm away from an external keyboard myself (travelling with a laptop).

Interestingly, I currently have the new tabs configured as Ctrl+_numpadX (_numpadX being a numpad key) at the moment (which works, as expected), but Ctrl+Shift+X (X being the corresponding top row number key) also seems to work. Not sure if that's because it's the default and isn't being unbound or because it's intended that the defaults continue to work even after remapping.

rensa on 23 Oct 2019

I dug up a keyboard with a numpad, and checked out what we're supposed to do (based on some other terminal emulators.)

It looks like Shift disengages numlock temporarily, across the board -- even Notepad responds as though you pressed the traditional arrow keys.

Ctrl+Shift+Numpad_4 (Left)

Now, as for why Windows Terminal can't _bind_ that combo ... Ctrl+Shift+Numpad4 literally comes into the application as "the user pressed Ctrl+←". ☹️

        + Key Down
        |                    + VK_LEFT  <<< Here
        v                    v
MESSAGE 00000100 004b0001 0025

        + Key Down
        |                    + VK_LSHIFT
        v                    v
MESSAGE 00000100 002a0001 0010

        + Key Up
        |                    + VK_SHIFT
        v                    v
MESSAGE 00000101 c02a0001 0010

        + Key Up
        |                    + VK_NUMPAD4
        v                    v
MESSAGE 00000101 804b0001 0064

Curiously, a real left arrow looks ever so slightly different (on an en-US PC 104 keyboard)

        + Key Down
        |         + A 1 here means "extended key"
        |         |          + VK_LEFT
        v         v          v
MESSAGE 00000100 014b0001 0025
MESSAGE 00000101 c14b0001 0025

DHowett-MSFT on 24 Oct 2019

👍1

Oh, wow! Yeah, just found a very old devblog post about it. That post notes that the same happens for CapsLock—although I daresay most people would expect a lowercase letter if you held shift and typed with the CapsLock engaged. Perhaps it was thought that analogous behaviour was appropriate for NumLock?

rensa on 24 Oct 2019

👍1

Unfortunately, on digging further (and reading Raymond Chen's blog here), it looks like this just isn't going to be something we can support. This is cooked into the lowest layers of either the input stack or into keyboards themselves. 😦

DHowett-MSFT on 2 Dec 2019

👍1

That's okay! It's possible that a settings UI (if that's in the works further down the line one day) could provide hints on key mappings that use Ctrl+Shift+Numpad, but perhaps that's a separate discussion.

rensa on 3 Dec 2019

As for the settings UI, the regex that I suggested in #2967 could be amended to not validate any combination with shift and numpad keys:

^(?<modifier>(ctrl|alt|shift)(?:\+(ctrl|alt|shift)(?<!\2))?(?:\+(ctrl|alt|shift)(?<!\2|\3))?\+)?(?<key>[^\s+]|backspace|tab|enter|esc|space|pgup|pgdn|end|home|left|up|right|down|insert|delete|(?<!shift.+)numpad_(?:[0-9]|period)|numpad_(?:multiply|plus|minus|divide)|f[1-9]|f1[0-9]|f2[0-4]|plus)$

Well, if you consider a JSON schema a "UI", of course.
(Try it out at Regex101)

Edit: Realized that not all numpad combos are affected by this limitation.