{{ message }}
Repository navigation
Handling shift in Keybindings #645
Description
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.
Activity
lzybkr commentedon Mar 12, 2018
Part of the motivation to ignore
Shiftwas for portability - on Linux/Mac,Console.ReadKeydoes not report the shift state in the same way that it does on Windows, so ignoringShiftseemed 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.