Handling shift in Keybindings

[FriedrichWeinmann]

Environment data

PS version: 6.0.1
PSReadline version: 2.0.0-beta1
os: 10.0.16299.15 (WinBuild.160101.0800)
PS file version: 6.0.1

Steps to reproduce or exception report

In custom keybindings, shift is being silently ignored.
According to #580 this is by design.

Handling bad input

If shift is not supported anymore, could you please throw an exception and refuse the binding, rather than silently stripping the Shift chord from the binding?

Just saying, but I have this Shift+Spacebar binding that expands aliases ... (made for a very interesting console experience)

On the design itself

I disagree with the design decision to prevent the use of the Shift key in bindings.

• 12 of the default bindings use it
• Enforces breaking change to existing bindings
• Keybindings must by their nature be interactive with a user at hand. Errors will be noticed.
• It needlessly halves the number of command key combinations available for mapping to the user of an OS that supports it (say: 'Windows')
• Why limit users to the smallest common set of keys, when there is obviously no technical limitation, it having been supported in previous versions.

[lzybkr]

Part of the motivation to ignore Shift was for portability - on Linux/Mac, Console.ReadKey does not report the shift state in the same way that it does on Windows, so ignoring Shift seemed necessary to keep things simple.

That said, because of other issues (related to AltGr), I have since implemented inferring the necessary shift state for keys on Windows, so for most key bindings, you don't need to (or want to really) specify Shift.

That said, as you point out, for some bindings, there's no way around it, and it does make sense to continue supporting custom bindings for those keys.