From: Marc Branchaud <marcnarc@xiplink.com>
Date: Fri, 13 Sep 2019 13:55:05 GMT
Subject: Re: [PATCH 2/2] git-gui: add hotkey to toggle "Amend Last Commit" check button/menu
Message-ID: <aabc98d9-52c4-45f5-fd8b-0d7ee530f263@xiplink.com>
In-Reply-To: <CAGr--=JDKrYT=Z8iwPVRy58OB9teH7bHXrYSZHqYHhJ=5wrJzQ@mail.gmail.com>

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
>