Re: [PATCH] gitk: replace SHA1 entry field on keyboard paste
On 3/4/2014 10:15 AM, Junio C Hamano wrote:
Show 13 quoted lines
> 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.
Show 20 quoted lines
> 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}
Ilya Bobyr
