public inbox for
help / color / mirror / Atom feed
From: "Matt D." <>
Subject: Re: Clipboard periodically breaks
Date: Mon, 21 Oct 2013 22:37:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


This was indeed fixed in the last version of XWin. Try updating.

However, copy/paste for large blocks of text seems to have broken.

Matt D.

On 10/21/2013 10:46 AM, Reinier Post wrote:
> On Thu Sep 26 20:35:21 2013, (Matt D.) wrote:
>> Jon,
>> 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.
> I'm reading this wich much interest: for me, too, copy-pasting
> between Windows applications and Cygwin xterms to break after some time,
> and this has been happening for a year or so.
> I'm not aware of doing anything special to cause it to break,
> but the only way I know how to fix it is to restart X.
> This is with recent Cygwin packages on Windows 7.
> I haven't tested with a newer build of the X server.
>> 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
>> programs:
>> $ 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?
> As an interested bystander, I have no doubt that that type of
> specific solution to specific clipboard interaction problems can
> possibly work, but using them will require detailed knowledge of how
> the X and Windows clipboards interact.
> My question is different: is it possible to implement the interaction
> in such a way that a user such as me, who is not aware of any subtleties,
> can get consistency, in the sense that all copy-paste actions between
> X an Windows that work when X is started continue to work in the same way
> for the duration of the session?
>> Matt D.

Unsubscribe info:
Problem reports:

  reply	other threads:[~2013-10-21 22:37 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.
2013-10-21 14:46             ` Reinier Post
2013-10-21 22:37               ` Matt D. [this message]
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).