public inbox for
help / color / mirror / Atom feed
From: "Matt D." <>
To: cygwin-xfree <>
Subject: Re: Clipboard periodically breaks
Date: Fri, 27 Sep 2013 00:35:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


Thanks for looking into this. I can confirm that your changes correct 
the issue where highlighting next would cause arbitrary pastes to occur. 
Good work!

I also concede that there does not seem to be a good solution to 
transparently fix the two-to-one clipboard issue; as XWin may indeed be 
able to interpret calls to X's two clipboards, there wouldn't be any 
reasonable way for it to identify which clipboard is actually being used.

However, an environment variable that tells it which clipboard to use 
would provide an immediate solution and be used used on a 
per-application basis. For example, I can use aliases when launching 

$ xclip=clipboard1 gedit $@ (monitor only clipboard 1)
$ xclip=clipboard2 gedit $@ (monitor only clipboard 2)

No option would indicate that both clipboard 1 and clipboard 2 would be 
handled as they are now.

I'm not familiar with X programming but I'm assuming here that it would 
be possible for xclip to read from a particular process's own 
environment (rather than xclip's own) while processing a clipboard event 
to do this.

What do you think?

Matt D.

On 9/26/2013 11:37 AM, Jon TURNEY wrote:
>> In-Reply-To: <>
> 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:
> 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]
> [2]
> [3]

Unsubscribe info:
Problem reports:

  parent reply	other threads:[~2013-09-27  0:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-09 18:59 64-bit Clipboard troubles David Stacey
2013-06-10 13:30 ` Jon TURNEY
2013-06-10 21:39   ` David Stacey
2013-06-21 12:33     ` Jon TURNEY
2013-06-21 18:02       ` David Stacey
2013-09-22  2:39       ` Clipboard periodically breaks Matt D.
2013-09-22  3:11         ` Matt D.
     [not found]         ` <>
2013-09-27  0:35           ` Matt D. [this message]
2013-10-21 14:46             ` Reinier Post
2013-10-21 22:37               ` Matt D.
2013-11-21 17:51               ` Jon TURNEY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).