From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112759 invoked by alias); 7 Feb 2018 14:26:27 -0000 Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com Received: (qmail 112745 invoked by uid 89); 7 Feb 2018 14:26:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=tunnel, Press, 4.=c2, 2?= X-HELO: out2-smtp.messagingengine.com Received: from out2-smtp.messagingengine.com (HELO out2-smtp.messagingengine.com) (66.111.4.26) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 14:26:20 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 478EB20F2E; Wed, 7 Feb 2018 09:26:18 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 07 Feb 2018 09:26:18 -0500 X-ME-Sender: Received: from [192.168.1.102] (host86-173-196-20.range86-173.btcentralplus.com [86.173.196.20]) by mail.messagingengine.com (Postfix) with ESMTPA id D4D2724522; Wed, 7 Feb 2018 09:26:17 -0500 (EST) Subject: Re: Spurious pastes To: mathog@caltech.edu, cygwin-xfree@cygwin.com References: <1e7a9c8c3f8625a43e1cef9cfcb95e12@saf.bio.caltech.edu> From: Jon Turney Message-ID: <7945947c-5872-ef24-0924-b86d39876749@dronecode.org.uk> Date: Wed, 07 Feb 2018 14:26:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2018-02/txt/msg00002.txt.bz2 On 02/02/2018 22:26, David Mathog wrote: > In the last few days nedit on those remote machines has been doing > spurious pastes. That is, whatever is currently in the X11 paste > buffer (not the program's paste buffer) is ending up dropped into > whatever file is being edited. Unclear why they are landing where > they do, I have not actually seen it happen, just found it when diff > indicated these odd insertions. My best guess is that these happen > while I am scrolling over these regions. Needless to say, this is > really not a good thing. > > There have been only two changes recently. > > 1. I cleaned my mouse. 2. yum on 1/27/18 automatically installed on > those servers: xorg-x11-server-common-1.17.4-16.el6.centos.1.x86_64 > > To eliminate (1) the mouse was swapped with another one. Too soon to > know if that did anything. I wonder if you aren't somehow accidentally clicking the middle mouse button whilst scrolling? > On 02-Feb-2018 13:13, David Mathog wrote: >> I seem to recall that before this if I highlighted a region in an >> xterm window, then moved to another X11 application window, and center >> clicked, it would paste the highlighted text.  However, if nothing was >> highlighted in the last window, nothing would paste.  My memory may be >> faulty on this issue though, as I never paid a lot of attention to it >> before it started misbehaving. > > That wasn't right, but cut/paste is slightly different between "on the > console" and "over putty ssh tunnel with X11 Server on Windows". > > On an XFCE4 ubuntu system console this is what happens: I'm guessing this means a non-X terminal? > 1.  type "pwd" into an uxterm window > 2.  highlight "pwd" on the line at the preceding prompt, center >     click once at the current prompt.  "pwd" is pasted. >     Press "enter". > 3.  left click once on the still highlighted "pwd", now 2 lines up. >     The highlight goes away.  Center click once at the prompt. >     "pwd" is still pasted. Press "enter". > 4.  With the left mouse button drag across any letter and back >     to the original position.  So nothing is highlighted.  This can >     be on any text anywhere in the window.  Center click >     at the prompt.  Nothing is pasted - the paste buffer is now >     empty. > > So on the console it is possible to select "nothing". > > On the X11 server ssh to the Ubuntu system and it is the same for the > first 3 steps, but the 4th still pastes "pwd".  The rule seems to be > "paste buffer can be replaced by anything selected, but not by a select > operation which ends with nothing highlighted." > > On the X11 server ssh to the Centos system, it behaves just like a > similar connection to the Centos system. > > The operations do the same thing when going between two uxterm windows > on any of these tests. > > Which is right?  Is "nothing" a valid thing to load into the paste > buffer or no? From the testing I did on a couple of linux systems, making an empty selection in urxvt doesn't change the clipboard contents, so I don't think this is specifically a Cygwin X server problem. I think it's up to the client (i.e. urxvt) how it interprets making an empty selection, which seems to be to not update the selection. > Is there a standard way to clear this buffer? I was going to suggest 'xsel -c' or 'xclip -i /dev/null', but that doesn't work (in this case) for obscure reasons to do with cut buffers... For future issues, can I ask you to use the cygwin list, per [1] [1] https://cygwin.com/ml/cygwin-xfree-announce/2015-03/msg00001.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/