In-Reply-To: <51C44820.4010307@dronecode.org.uk>
Please start a new thread for a new subject.
On 22/09/2013 03:38, Matt D. wrote:
I often keep gedit sessions open on remote servers for maintaining various
scripts. The problem I've encountered is that after a while I can no
longer copy/paste between X and Windows.
For example, I'll copy in windows and attempt to paste in gedit but nothing
will happen. However, if I then proceed to copy something in gedit it will
immediate "paste" that in place of where I had previously tried to paste
from Windows.
Sometimes I can get it working again by bombarding the clipboard with
copy/pastes from both X and Windows. But most of the time I have to exit
the ssh session and reconnect.
Is this a known problem?
We know there are bugs, but we don't know what they all are :-)
Here is an example screen capture and repeatable bug of the clipboard
breaking.
Synopsis: Copy from Windows, highlight text in gedit, clipboard breaks
(paste doesn't work). Proceed to copy from gedit and suddenly that text
gets pasted. Sometimes it will just start pasting while a selection is
being made.. ??
Download the video here in Xvid format:
http://codespunk.com/files/upload/cygwinx_clipboard_breaking_xvid.avi
Thanks for this.
There's definitely a bug here when stuff fails to paste.
You are also having difficulties because of a limitation of the current
clipboard implementation I'll try to explain:
As [1] tries to explain, there are 2 X selections of interest, the PRIMARY
selection (the highlighted text) and the CLIPBOARD selection (the cut/copied
text) (and some X applications only use one or the other), but only 1 windows
clipboard.
When you update the PRIMARY selection, by highlighting that text, it is made
available for pasting from the Windows clipboard, which means that the
previous Windows clipboard contents are removed. When you then go to paste,
since the Windows clipboard contents have changed to the selected text, that's
what you get in the CLIPBOARD selection.
This is far from idea, but the proposed solutions I've seen so far aren't any
better:
i) Don't monitor the PRIMARY selection. This breaks with any application
which only uses the PRIMARY selection (e.g. xterm, emacs in default
configurations)
ii) Use some more complex heuristic than 'most recently changed owner' for
choosing which selection to make available in the Windows clipboard. It's
very hard to know if this will make things better on average.
I've fixed something else that might be related to the paste failure, so
please try the latest snapshot [2],[3].
If you can still reproduce your problem with that, can you please try:
* run XWin with the -noclipboard flag added to your usual flags.
* Then run xwinclip, which should produce some useful logs when you reproduce
your problem.
[1] http://x.cygwin.com/docs/ug/using-clipboard-integration.html
[2] ftp://cygwin.com/pub/cygwinx/XWin.20130924-git-d5a9aea0e48a088b.exe.bz2
[3] ftp://cygwin.com/pub/cygwinx/xwinclip.20130924-git-d5a9aea0e48a088b.exe.bz2