Kupfer does not read current selection correctly from gVim

[Alex Bepple]

When I visually select something in gVim and invoke Kupfer’s “Show with selection”, the wrong string is shown. I suspect this to be Kupfer’s fault or one of its dependencies’, since `xclip -o` shows the correct selection.

In order to reproduce:
* Enter “foo” in gVim, switch to Normal mode and go to the beginning of the line.
* Press ‘v’ to enter Visual mode.
* Invoke Kupfer with the selection. It correctly shows “f”.
* In gVim, extend the selection one character to the right by pressing ‘l’.
* Invoke Kupfer with the selection. Incorrectly, it still shows “f”. `xclip -o` gives “fo”, as would be expected.

[William Friesen (william-friesen)]

This seems to be an issue with the "owner-change" signal of gtk.Clipboard.
In regards to GVim, this signal is emitted once Visual mode is first entered, but not each time the selection is changed.

[X (u78qir8a9-deactivatedaccount)]

William I think you are absolutely correct.

I don't want to change the Clipboard object into a "completely dynamical" object (it would query GTK for clipboard at the instant when the text is used) -- the reason is simple, it could create race conditions in the code since the object's value could be accessed (and then changed) at any time. We can't call GTK at just anytime in the code.

Maybe we can find another change notification to solve this. I have gvim, and maybe able to try it out.

[Alex Bepple (alex.bepple)]

How about querying the clipboard when Kupfer is summoned? As a user I do not expect any clipboard changes while I interact with Kupfer anyway.

[X (u78qir8a9-deactivatedaccount)]

I don't know. There is no summoning callback for kupfer plugins.

[X (u78qir8a9-deactivatedaccount)]

I can't reproduce this with the latest version. I'm using vim-gtk (debian) 7.3 + 1-154

[Alex Bepple (alex.bepple)]

I do not use Linux any longer, so I cannot provide any further information on this issue.

[X (u78qir8a9-deactivatedaccount)]

If you're going to OS X just to use Quicksilver, I will forgive you. Otherwise.. not :-)

Putting this bug into incomplete mode => needs more information.