Terminal: Font size can't be changed while using + and - from numeric keypad

[amithegde]

Environment

Microsoft Windows [Version 10.0.19041.450]
Windows Terminal version (if applicable): latest preview

Steps to reproduce

• Hold Ctrl and press + or - from numeric keypad

Expected behavior

• font size should increase or decrease

Actual behavior

• nothing happens

[DHowett]

Yup. + and Keypad + are different keys and generate different inputs to the OS. If you'd like to bind these specifically, you can add your own custom bindings for ctrl+numpad_plus and ctrl+numpad_minus.

[amithegde]

• and Keypad + are different keys and generate different inputs to the OS

@DHowett that is very interesting! It would be great to have these configured as default settings. I use terminal on at least 4 devices and it would be nice to have these included in the default settings as one doesn't have to do lot of manual configurations just to make it work.

On the other hand, I wonder how the numbers on the numeric keypad work without needing additional configuration 🤔🤔

[DHowett]

Terminal would rather not camp on any more of your keyboard keys than it really absolutely needs to! :grin:

The numbers actually are different keys too (VK_NUMPAD0 through VK_NUMPAD9) and any bindings set on them need to be set for the numpad numbers specifically.

These keys work work normally when sent to the client application because while the terminal's key bindings operate on _keys_, the communication protocol relies on _characters_[1].

key|vkey|character
-|-|-
1|VK_1|1
Numpad 1|VK_NUMPAD1|1

[amithegde]

I noticed VS code handles + on the numeric keypad👌

[pstaag]

(I literally signed up just to join the discussion in this particular thread. Uh...be gentle with me. I, well, need a markup crash course, among other things.)

@amithegde is on to something here. There ARE key bindings missing. But...I'd prefer to go one or perhaps several steps further.

First,

Yes. Absolutely do bind ctrl+numpad plus.

Why? Because it's bound in a lot of web browsers to have zoom behaviour. Consistency is sometimes about availing plenty different ways to do the same thing.

Second,

Also add other key bindings. Because,

1. on portables without a numpad keyboard, it's flat out useless to have that binding. It offers no difference.

2. Windows built in keyboard does not have a numpad. It's a change that does not help users relying on it.

3. Cater better to the international user community.

For me, being friends with Swedish keyboard layouts in particular, there is a problem with producing ctrl+= because = is shift:ed on 0. Windows Terminal does not understand ctrl+shift+0 as ctrl+= (which is probably correct behaviour, I'm not complaining) and therefor, the official key binding is, literally, impossible to invoke (and THAT, that last bit, I totally am complaining about.)

For me, it's annoying like there is no tomorrow that ctrl++ is not bound to zoom alongside with ctrl+=

It also does not help that the Command Palette insists that Increase font size IS bound to +shift+0

1. Mimic behaviour from other types of software to cut down on the learning curve

Adding several key bindings to the same behaviour is sometimes the best way to remove a learning curve for new users. Web browsers typically add several key bindings that control zoom. Add a few more of them to the official list of bindings.

Navigating key bindings can prove to be a bit of a headache, because we also don't want to make the terminal useless in the process. But...

This last bit should probably be lifted to another thread, to not derail this discussion further:

While we are at it, have you noticed that the new Command Palette only shows the first defined key binding for a command? Even if I bind ctrl++ it still insists in showing JUST the defaults.json binding.

The command palette deserves standing ovations already, but it totally also needs more work.

[DHowett]

@pstaag thanks :) those are all very valid points. I’ll reopen this and hit it again in triage tomorrow during the work day.

[pstaag]

After giving it some thought, I decided that how key bindings on numeric keys are handled in Terminal, is an actual, proper bug and deserved it's own thread. It's in #7539