From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: Issues with X selection handling Date: Tue, 24 Aug 2004 13:44:03 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <412B2A03.8080309@swipnet.se> References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1093347969 5536 80.91.224.253 (24 Aug 2004 11:46:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 24 Aug 2004 11:46:09 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 24 13:46:01 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BzZkX-0008O9-00 for ; Tue, 24 Aug 2004 13:46:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BzZp2-0003EO-8V for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2004 07:50:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BzZor-0003Dh-KQ for emacs-devel@gnu.org; Tue, 24 Aug 2004 07:50:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BzZoq-0003DA-2B for emacs-devel@gnu.org; Tue, 24 Aug 2004 07:50:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BzZop-0003Cr-WA for emacs-devel@gnu.org; Tue, 24 Aug 2004 07:50:28 -0400 Original-Received: from [195.54.107.73] (helo=mxfep02.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BzZjQ-0002Mh-Er for emacs-devel@gnu.org; Tue, 24 Aug 2004 07:44:52 -0400 Original-Received: from coolsville.localdomain ([213.115.26.74] [213.115.26.74]) by mxfep02.bredband.com with ESMTP id <20040824114451.HZDK345.mxfep02.bredband.com@coolsville.localdomain>; Tue, 24 Aug 2004 13:44:51 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040810 X-Accept-Language: en-us, en Original-To: Davis Herring In-Reply-To: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:26441 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26441 Davis Herring wrote: >>> + `x-disown-selection-internal' doesn't seem to do anything. >> >>Well, it disowns the selection, but it does not call any hooks if that is what >>you mean. Can you please say what you expected it to do? > > > I see -- it does disown the selection, but not only are no hooks called > (the docstring for `x-lost-selection-hooks' explicitly says it should be > called), but the entry is not removed from the internal variable > `Vselection-alist'. This means Emacs (in Lisp) thinks it still owns the > selection and that it has the value it had before the disownment. The mishandling of Vselection-alist is a bug. I have corrected it in CVS. The hooks are also called after this correction. > They disagree a notable amount of the time, and `x-lost-selection-hooks' > is never called with PRIMARY as an argument unless the keyboard is used to > kill text. Meanwhile CLIPBOARD appears to call the hooks every time. I still can not reproduce this. You need to supply an explicit test case, i.e. a step by step description of how to reproduce this. > Stranger still is that occasionally one Emacs generates messages in the > other that look like this: > > Sent selection at Mon Aug 23 18:57:44 2004: (CLIPBOARD nil nil) > Sent selection at Mon Aug 23 18:57:44 2004: (CLIPBOARD nil nil) > Sent selection at Mon Aug 23 18:57:44 2004: (PRIMARY nil nil) > Sent selection at Mon Aug 23 18:57:44 2004: (PRIMARY nil nil) > > The Emacs requesting the selection isn't sending any type with its > request, apparently; it gets declined, and decides that there is no such > selection. It is. It is just that the Emacs that prints this does not have the selection. Then the second and third argument will be nil. It is probably a race condition in your test set up. Jan D.