On 2019-09-13 3:50 a.m., Birger Skogeng Pedersen wrote:
Hi Marc and Philip,
On 12/09/2019 22:34, Marc Branchaud wrote:
I disagree! Who expects anything to work properly when capslock is on?
Me :-)
Fair enough, though I imagine you have a pretty narrow definition of
"anything". :)
On Fri, Sep 13, 2019 at 12:23 AM Philip Oakley <philipoakley@iee.email> wrote:
I'd tend to agree. In other areas the use of shift is often used as the
complement of the unshifted action, so it does feel 'odd'. Thus it could
be used directly as the bool for amend or direct commit.
This all assumes that Caps Lock is equivalent to having the shift on,
rather than being a special extra key.
It seems all the Ctrl+(lowercase character) hotkeys in git-gui have an
equivalent Ctrl+(uppercase character).
So for this feature, we should keep the Ctrl+E bind aswell as the
Ctrl+e bind. If nothing else, to keep it consistent with the rest of
the hotkey bindings.
Ah, OK. I agree that keeping git-gui internally consistent trumps the
other considerations.
M.
But honestly, (as Marc pointed out) it is a quite weird that
Ctrl+Shift+(character) has the excact same function as
Ctrl+(character). Perhaps we should find another way to bind the
hotkeys, where the state of Caps Lock doesn't matter? If possible.
Birger
