Re: [PATCH] gitk: replace SHA1 entry field on keyboard paste

[Ilya Bobyr <illia.bobyr@gmail.com>]

On 3/4/2014 10:15 AM, Junio C Hamano wrote:
> From: Ilya Bobyr <ilya.bobyr@gmail.com>
> Date: Thu, 27 Feb 2014 22:51:37 -0800
>
> We already replace old SHA with the clipboard content for the mouse
> paste event.  It seems reasonable to do the same when pasting from
> keyboard.
>
> Signed-off-by: Ilya Bobyr <ilya.bobyr@gmail.com>
> ---
>
>   * Paul?  I do not use <<Paste>> on my keyboard, so I am not in the
>     position to say that this patch is correct (or not).  I am just
>     forwarding it in case you think gitk users will find it useful.

I should have included a cover letter with additional details on what is 
this.
I am still a bit new to the process, so I did not realize it would be 
useful until now.

<<Paste>> is the "clipboard paste" shortcut.  Ctrl+V on WIndows and Ubuntu.

SHA fields in gitk is a text field that accepts focus.  My expectation 
is that I can replace SHA already in there with one I have in the clipboard.
The problem is that I was not able to find an easy way.  Not immediately 
at least.
Here is what I observed:
1. If I just click in there and press Ctrl+V, SHA from the clipboard is 
inserted in the spot that I clicked.  Most cases in the middle of the 
SHA symbols already in there.
      Fixing the mess afterwards in just impossible.
2. If I double click "old" SHA in order to select and delete it before 
the paste, selected text is automatically copied into the clipboard (at 
least on Cygwin).
     While the SHA field is now empty to accept "new" SHA, the clipboard 
content is lost and I have to go copy new SHA into the clipboard again.
3. I can click once to give SHA field keyboard focus, delete whatever is 
there using Delete and/or Backspace and then paste new SHA.
     While this works it is not very convenient.  I also keeped pressing 
Ctrl+W to "delete a word" that was closing gitk window completely %)

Now, it turned out that if I use mouse to do the paste, not the 
keyboard, it does do what actually makes sense: removes old SHA and 
pastes the new one.
As SHA's are atomic, there seems to be no value in been able to insert 
one in the middle of another.

The bug, as I see it, is that it happens only if mouse paste is used.  
That would be the "<<PasteSelection>>" in the line above the added one.

When keyboard paste is used old SHA is not cleared.

I guess one would say that inserting with the mouse is actually easier, 
but been a Windows user it was unusual to me to use mouse paste in the GUI.
I have never even thought to do that and was struggling for quite a while.

The patch makes both mouse and keyboard paste work the same.
I think that could help someone else who is not used to mouse paste in 
the GUI text boxes as well.

>     The original patch was done against my tree, so I hand tweaked it
>     to apply to your tree.
>     
>     Thanks.
>
>   gitk |    1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/gitk b/gitk
> index 90764e8..2f58bcf 100755
> --- a/gitk
> +++ b/gitk
> @@ -2585,6 +2585,7 @@ proc makewindow {} {
>       bind $fstring <Key-Return> {dofind 1 1}
>       bind $sha1entry <Key-Return> {gotocommit; break}
>       bind $sha1entry <<PasteSelection>> clearsha1
> +    bind $sha1entry <<Paste>> clearsha1
>       bind $cflist <1> {sel_flist %W %x %y; break}
>       bind $cflist <B1-Motion> {sel_flist %W %x %y; break}
>       bind $cflist <ButtonRelease-1> {treeclick %W %x %y}