git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Pratyush Yadav <me@yadavpratyush.com>
Date
Oct 5, 2019, 21:01 UTC
Message-ID
<20191005210127.uinrgazj5ezyqftj@yadavpratyush.com>
In-Reply-To
<149a83fd40b71896b134b16c2b499ff472c6234e.camel@gmail.com>
On 06/10/19 01:46AM, Harish Karumuthil wrote:
Show 7 quoted lines
> Hi All,
> 
> From https://www.kernel.org/doc/html/v4.10/process/email-clients.html, I
> understood that, my current email client ( that is gmail web ) is not good
> for submitting patches. So I was tying to setup a mail client which is
> compatible with `git send-mail`. But I was not able to get a satisfactory
> result in that.

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.

So what you should do is run `git format-patch -o feature master..HEAD`, assuming your feature branch is checked out. This will give you a set of '.patch' files depending on how many commits you made in your branch in the folder feature/. Then, you can run

  git send-email --to='Pratyush Yadav <me@yadavpratyush.com>' --cc='<git@vger.kernel.org>' feature/*.patch

This will send all your patch files via email to me with the git list in Cc. You can add multiple '--to' and '--cc' options to send it to multiple people.

Try sending the patches to yourself to experiment around with it.

A pretty good tutorial to configuring and using git-send-email can be found at [0]. And of course, read the man page.

These instructions are for Linux, but you can probably do something 
similar in Windows too (if you're using Windows that is).
 
> For now, I followed the instruction of Johannes Schindelin and submitted a
> pull request . Please see https://github.com/gitgitgadget/git/pull/376

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.

But I see that Dscho has left a comment over there, so you should 
probably address that first. You probably need to amend the commit, 
force push, and then comment with '/submit'. But I'm not a 100% sure 
because I haven't used GitHub PRs a lot.
 
Show 14 quoted lines
> ---------
> @ Pratyush: Regarding your comments,
> 
> 
> > A pretty nice way of doing it. But I would _really_ like it if there was
> > an option in the "create tool" dialog to specify the shortcut. People of
> > a gui tool shouldn't have to mess around with config files as much as
> > possible.
> 
> I agree with this, But that may require some more profficiency in TCL/TK
> programming which I don't have. This is the first time I am looking into a
> TCL/TK source code.
> Any way I will try to integrate the gui gradually in feature. But
> unfortunatly, I may not be able to do that now.
Please do whatever you can. I will try to add a patch on top of yours to 
add the GUI option.
 
Show 16 quoted lines
> > David has advocated inter-operability between git-gui and git-cola.
> > While I personally don't know how many people actually use both the
> > tools at the same time, it doesn't sound like a bad idea either.
> >
> > So, sharing shortcuts with git-cola would be nice. Of course, it would
> > then mean that we would have to parse the config parameter before
> > feeding them to `bind`. I don't suppose that should be something too
> > complicated to do, but I admit I haven't looked too deeply into it.
> 
> IMHO, Using a uniform shortcut-key code/foramat for both application can be
> considered as nice feature.
> But, whether we should share common shortcut-scheme with both application is
> a different question.
> Currently, both apps don't have a common shortcut-scheme. So in this
> situation, only sharing custom-tool's shortcut-scheme with both applications
> doesn't look like a good  idea to me 
Makes sense.
 
Show 17 quoted lines
> > Are you sure that is a good idea? I think we should at least make 
> > sure
> > we are not binding some illegal sequence, and if we are, we should warn
> > the user about it. And a much more important case would be when a user
> > over-writes a pre-existing shortcut for other commands like "commit",
> > "reset", etc. In that case, the menu entires of those commands would
> > still be labelled with the shortcut, but it won't actually work.
> 
> I agree with you. It is an important point. After reading this, I checked
> current status of these issues. What I found is given below.
> 
> 1. When user provides an invalid sequence for the shortcut, it will cuase the
> entire gitgui application to crash at the startup
> 
> 2. When user tries to overwrite existing shortcut, it will not have any
> effect. Because, built in shortcuts will overwrite user provided one. But
> still, wrong menu accelerator label will persist for custom tools

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 :).

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.

> Since #1 is a serious issue, I tried to find out the function which does the
> keycode validation, but I haven't succeded till now. ( I found the C function
> name  which is "TkStringToKeysym" from TK source, but I couldn't find its TCL
> binding ). It will be helpful if any one can help me on this.

I really think you shouldn't dive around in the C parts of Tcl. I haven't looked too deeply into this, but you can probably wrap your bind calls in `catch` [2] and handle errors from there. Again, I haven't tried actually doing this, so you do need to check first.

You can find examples of how to use `catch` in our codebase. Just search for it.

[0] https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/ [1] https://www.tcl.tk/man/tcl8.4/TkCmd/bind.htm [2] https://www.tcl.tk/man/tcl8.4/TclCmd/catch.htm

-- 
Regards,
Pratyush Yadav
Previous: Harish KarumuthilNext: Johannes Schindelin
Message 9 of 27 in “Feature: custom guitool commands can now have custom keyboard shortcuts”
  1. Feature: custom guitool commands can now have custom keyboard shortcutsHarish K, Mar 29, 2016
  2. David AguilarMar 31, 2016
  3. harish kApr 1, 2016
  4. harish kOct 3, 2019
  5. Pratyush YadavOct 3, 2019
  6. Johannes SchindelinOct 4, 2019
  7. Pratyush YadavOct 4, 2019
  8. Harish KarumuthilOct 5, 2019
  9. Pratyush YadavOct 5, 2019
  10. Johannes SchindelinOct 6, 2019
  11. Pratyush YadavOct 6, 2019
  12. Philip OakleyOct 6, 2019
  13. Johannes SchindelinOct 6, 2019
  14. Pratyush YadavOct 6, 2019
  15. GitGUIGadget, was Re: [PATCH] Feature: custom guitool commands can now have custom keyboard shortcutsJohannes Schindelin, Oct 7, 2019
  16. Birger Skogeng PedersenOct 7, 2019
  17. Alban GruinOct 7, 2019
  18. Making GitGitGadget's list -> PR comment mirroring bidirectional, was Re: [PATCH] Feature: custom guitool commands can now have custom keyboard shortcutsJohannes Schindelin, Nov 19, 2019
  19. Pratyush YadavNov 20, 2019
  20. Philip OakleyOct 6, 2019
  21. Harish KarumuthilOct 7, 2019
  22. Johannes SchindelinOct 7, 2019
  23. Harish KarumuthilOct 8, 2019
  24. Johannes SchindelinOct 9, 2019
  25. Pratyush YadavOct 13, 2019
  26. Harish KarumuthilOct 7, 2019
  27. Pratyush YadavOct 13, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.