Re: [PATCH] Feature: custom guitool commands can now have custom keyboard shortcuts

From: Pratyush Yadav <me@yadavpratyush.com>
Date: Oct 13, 2019, 19:17 UTC
Message-ID: <20191013191710.535nho3pec2c5wlk@yadavpratyush.com>
In-Reply-To: <1dbb69d96229fa9400d7eae0b4fd467ab9706815.camel@gmail.com>

Hi Harish,

Sorry for the late reply. Couldn't find much time last few days.

On 07/10/19 11:43AM, Harish Karumuthil wrote:

Show 14 quoted lines

> Hi Pratyush, Regarding your messages,
> 
> >On Sun, 2019-10-06 at 02:31 +0530, Pratyush Yadav wrote:
> > You don't need to "set up" an email client with git-send-email. 
> > git-send-email is an email client itself. Well, one which can only send 
> > emails.
> 
> For now, I am sticking with a mail client ( evolution ) which does minimal
> ( or atleast transparent ) preprocessing  ( Tab => space conversion , line
> wrapping  etc ).
> Now I can send patches using the output of `git diff --patch-with-stat`
> command and I hope is it enough for now.
> Personaly I dont' like any solution which requires storing our mail password
> as a plain text file.

I'm afraid this won't work. The '.patch' file that `git-format-patch` generates also contains your commit message and the author information. All those are needed to properly convert your patch to a commit in my repo. The output of `git diff --patch-with-stat` won't be enough.

As for not wanting to store your mail password in a plain text file, check out [0].

And then there is GitGitGadget too, which I'd recommend since you seem 
to be having trouble sending patches directly :).

Show 7 quoted lines

> > You haven't sent '/submit' over there, so those emails aren't in the 
> > list (and my inbox) yet. You need to comment with '/submit' (without 
> > the quotes) to tell GitGitGadget to send your PR as email.
> 
> I thought, lets finalize discussion about all the changes here in mail
> thread   it self before submitting the patch. Otherwise, That is why I didn't
> submitted the patch.

Makes sense.

Show 16 quoted lines

> > One point I forgot to mention earlier was that I'm honestly not a big 
> > fan of separating the binding and accelerator label. I understand that 
> > you might not have the time to do this, but I think it is still worth 
> > mentioning. Maybe I will implement something like that over your patch. 
> > But it would certainly be nice if you can figure it out :).
> 
> I think there is a small missunderstanind in that point.
> 
> I agree that, in the initial implementation ( which I did @ 2016 ) menu
> labels were separated from binding keys. But in the last update, it is not
> like that.
> 
> Currently, user only need to specify single config value which is
> `guitool.<name>.gitgui-shortcut` and don't have to specify accel-lable
> separatly.
> Label is generated from the shortcut.

Thanks for clarifying. It indeed was a misunderstanding.

Show 11 quoted lines

> > Either ways, detecting an existing shortcut is pretty easy. The `bind` 
> > man page [1] says:
> > 
> >   If sequence is specified without a script, then the script currently 
> >   bound to sequence is returned, or an empty string is returned if there 
> >   is no binding for sequence.
> > 
> > So you can use this to find out if there is a binding conflict, and warn 
> > the user.
> 
> Will try this. Thanks!

[0] https://www.softwaredeveloper.blog/git-credential-storage-libsecret

-- 
Regards,
Pratyush Yadav