From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Davis Herring Newsgroups: gmane.emacs.devel Subject: Re: Issues with X selection handling Date: Mon, 23 Aug 2004 19:18:25 -0600 (MDT) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <4124EC71.2050406@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1518306044-1068664010-1093310305=:31548" X-Trace: sea.gmane.org 1093310347 30718 80.91.224.253 (24 Aug 2004 01:19:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 24 Aug 2004 01:19:07 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 24 03:18:56 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 1BzPxf-00041l-00 for ; Tue, 24 Aug 2004 03:18:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BzQ28-0008Fm-U9 for ged-emacs-devel@m.gmane.org; Mon, 23 Aug 2004 21:23:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BzQ21-0008FT-9x for emacs-devel@gnu.org; Mon, 23 Aug 2004 21:23:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BzQ1z-0008Ep-7d for emacs-devel@gnu.org; Mon, 23 Aug 2004 21:23:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BzQ1z-0008Em-5L for emacs-devel@gnu.org; Mon, 23 Aug 2004 21:23:23 -0400 Original-Received: from [192.65.95.54] (helo=mailwasher-b.lanl.gov) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BzPxE-0004PQ-Q2 for emacs-devel@gnu.org; Mon, 23 Aug 2004 21:18:29 -0400 Original-Received: from mailrelay2.lanl.gov (localhost.localdomain [127.0.0.1]) by mailwasher-b.lanl.gov (8.12.10/8.12.10/(ccn-5)) with ESMTP id i7O1IQ6U005098 for ; Mon, 23 Aug 2004 19:18:26 -0600 Original-Received: from x-mail.lanl.gov (localhost.localdomain [127.0.0.1]) by mailrelay2.lanl.gov (8.12.10/8.12.10/(ccn-5)) with ESMTP id i7O1IQVU019291; Mon, 23 Aug 2004 19:18:26 -0600 Original-Received: from x-mail.lanl.gov (localhost.localdomain [127.0.0.1]) by x-mail.lanl.gov (8.12.10/8.12.10/(ccn-5)) with ESMTP id i7O1IQu6001596; Mon, 23 Aug 2004 19:18:26 -0600 Original-Received: from localhost (herring@localhost) by x-mail.lanl.gov (8.12.10/8.12.10/Submit) with ESMTP id i7O1IPBB001592; Mon, 23 Aug 2004 19:18:25 -0600 X-Authentication-Warning: x-mail.lanl.gov: herring owned process doing -bs Original-To: "Jan D." In-Reply-To: <4124EC71.2050406@swipnet.se> X-Scanned-By: MIMEDefang 2.35 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:26435 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26435 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1518306044-1068664010-1093310305=:31548 Content-Type: TEXT/PLAIN; charset=US-ASCII [These experiments conducted on 21.3.1 on GNU/Linux with XFree86.] On Thu, 19 Aug 2004, Jan D. 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. > > + `x-lost-selection-hooks' is not always executed when one would expect: > > - using the mouse to select text in Emacs and then elsewhere seems to > > never call the hooks > > I have not been able to reproduce this with the CVS version or 21.3. > The lost and send hooks are always called, for PRIMARY and CLIPBOARD. > Can you test the CVS version? Unfortunately I can't test the CVS version -- at least, not quickly. Beyond that I don't know what to say to this, except to try out the attached test code (I've updated it somewhat since my prior postings). What I'm trying now is running two Emacsen with the same continuous-sampling setup, and alternating between them making selections. 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. 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. As for the mouse-selection, a mouse-drag after a keyboard event doesn't even call `post-command-hook' until the next event is received (at which point the hook is called twice); if I mouse-drag, then tap a key, and -then- select text elsewhere, the lost-hook is called as I expect. So there may be a race between the "completion" of the mouse-drag and the reception of the "selection stolen" event. This would explain the bizarre "keyboard-dependence". Of course, it seems to me as though the very delay of such "completion" of a mouse command is a much worse problem. Is there some reason for this? > > - losing the clipboard usually (but not always) calls the hooks As an unexpectedly final test, aiming to decide this issue, I mouse-selected text in one Emacs, then immediately went to the other and evaluated Lisp to grab only the clipboard. Both Emacsen immediately froze. This, I suppose, is a separate issue worthy of consideration. The CLIPBOARD/PRIMARY asymmetry is surely some sort of indication as to the nature of the bug (since there's no real reason for the selections to behave differently), but it might be something as trivial as "the first event is lost, and that's usually PRIMARY". > > + Occasionally, Emacs itself (i.e. xselect.c) seems to miss a > > notification that it has lost the selection -- I have, once, seen Emacs > > insist that it owns the clipboard selection despite the fact that other > > applications are owning and using it. This must have been the result of manually disowning a selection; I see now that this isn't a separate issue. > We really need a solid test case that always fails to be able to find any bug > in this area. All these behaviors are pretty deterministic as far as I can tell. Hopefully this additional information (and updated testing code) is helpful. Davis Herring -- This product is sold by volume, not by mass. If it seems too dense or too sparse, it means mass-energy conversion has occurred during shipping. ---1518306044-1068664010-1093310305=:31548 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="testing.el" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: X Selection Test Code Content-Disposition: attachment; filename="testing.el" OzsgW0Zyb20gbXkgZXhjZXNzaXZlIC5lbWFjczogdXNlZCBmb3IgY3V0LWJ1 ZmZlcnMgYmVsb3cuXQ0KKHJlcXVpcmUgJ2NsKQ0KKGRlZm1hY3JvIHRhYmxl ICh2YXIgY291bnQgZm9ybSkNCgkiRXZhbHVhdGUgRk9STSBDT1VOVCB0aW1l cywgd2l0aCBWQVIgYm91bmQgdG8gaW50ZWdlcnMgZnJvbSAwIHRvIENPVU5U LTEuDQpSZXR1cm4gYSBsaXN0IG9mIHRoZSByZXN1bHRzIG9idGFpbmVkLg0K SWYgVkFSIGlzIGBuaWwnLCBiaW5kIG5vdGhpbmcsIGp1c3QgbG9vcC4iDQoJ KGxldCAoKGxpc3RzeW0gKGdlbnN5bSAidGFibGU6Omxpc3QiKSkNCgkJCQko dGFpbHN5bSAoZ2Vuc3ltICJ0YWJsZTo6dGFpbCIpKQ0KCQkJCShpdGVyYXRv ciAob3IgdmFyIChnZW5zeW0gInRhYmxlOjppdGVyYXRvciIpKSkNCgkJCQko Y291bnRzeW0gKGdlbnN5bSAidGFibGU6OmNvdW50IikpKQ0KCQlgKGxldCog KCgsaXRlcmF0b3IgLTEpICgsY291bnRzeW0gLGNvdW50KQ0KCQkJCQkJKCxs aXN0c3ltIChsaXN0IG5pbCkpICgsdGFpbHN5bSAsbGlzdHN5bSkpDQoJCQkg KHdoaWxlICg8IChzZXRxICxpdGVyYXRvciAoMSsgLGl0ZXJhdG9yKSkgLGNv dW50c3ltKQ0KCQkJCSAoc2V0cSAsdGFpbHN5bSAoc2V0Y2RyICx0YWlsc3lt IChsaXN0ICxmb3JtKSkpKQ0KCQkJIChjZHIgLGxpc3RzeW0pKSkpDQoNCihk ZWZ2YXIgeC1zZWxlY3Rpb24tZXJyb3JzIG5pbCkNCg0KKGRlZnVuIHgtZ2V0 LXNlbGVjdGlvbi1uby1lcnJvciAoc2VsIHR5cGUpDQoJKGNvbmRpdGlvbi1j YXNlIGUgKHgtZ2V0LXNlbGVjdGlvbi1pbnRlcm5hbCBzZWwgdHlwZSkNCgkJ KGVycm9yIChhZGQtdG8tbGlzdCAneC1zZWxlY3Rpb24tZXJyb3JzIGUgdCkg bmlsKSkpDQoNCihkZWZ1biB4LXNlbGVjdGlvbi1yZXBvcnQgKHMpDQoJKGxp c3QgcyAoeC1zZWxlY3Rpb24tb3duZXItcCBzKQ0KCQkJCShsZXQgKChjdCAo eC1nZXQtc2VsZWN0aW9uLW5vLWVycm9yIHMgJ0NPTVBPVU5EX1RFWFQpKQ0K CQkJCQkJCShzdHIgKHgtZ2V0LXNlbGVjdGlvbi1uby1lcnJvciBzICdTVFJJ TkcpKSkNCgkJCQkJKGlmIGN0IChsaXN0ICdDT01QT1VORF9URVhUIGN0KSAo bGlzdCAnU1RSSU5HIHN0cikpKSkpDQoNCihkZWZ2YXIgeC1zZWxlY3Rpb24t Y291bnRlciAwKQ0KDQooZGVmdW4geC1kZXNjcmliZS1zZWxlY3Rpb25zICgm cmVzdCBpZ25vcmUpCTsgYWxsb3cgdXNlIG9uIGFueSBob29rDQoJKGludGVy YWN0aXZlKQ0KCSh3aXRoLWN1cnJlbnQtYnVmZmVyIChnZXQtYnVmZmVyLWNy ZWF0ZSAiKlggU2VsZWN0aW9ucyoiKQ0KCQkoZXJhc2UtYnVmZmVyKQ0KCQko cHAgKGxpc3QgKGxpc3QgKGZvcm1hdCAiJS0zcyINCgkJCQkJCQkJCQkJCQkJ KG1ha2Utc3RyaW5nIChzZXRxIHgtc2VsZWN0aW9uLWNvdW50ZXINCgkJCQkJ CQkJCQkJCQkJCQkJCQkJCQkJICglICgxKyB4LXNlbGVjdGlvbi1jb3VudGVy KSA0KSkgPyopKQ0KCQkJCQkJCQkJCShpbnB1dC1wZW5kaW5nLXApKQ0KCQkJ CQkJCSh4LXNlbGVjdGlvbi1yZXBvcnQgJ0NMSVBCT0FSRCkNCgkJCQkJCQko eC1zZWxlY3Rpb24tcmVwb3J0ICdQUklNQVJZKQ0KCQkJCQkJCSh4LXNlbGVj dGlvbi1yZXBvcnQgJ1NFQ09OREFSWSkNCgkJCQkJCQkodGFibGUgaSA4IChj b25zIGkgKHgtZ2V0LWN1dC1idWZmZXIgaSkpKSkgKGN1cnJlbnQtYnVmZmVy KSkpKQ0KDQo7OyBSZXR1cm5zIGEgbGFtYmRhIHdoaWNoIHByZXR0eS1wcmlu dHMgbGlzdCBvZiBpdHMgYXJndW1lbnRzIHdpdGggYSBoZWFkZXINCihkZWZ1 biBwcC1sYW1iZGEgKGJ1ZiBzdHIpDQoJYChsYW1iZGEgKCZyZXN0IGFyZ3Mp DQoJCSAod2l0aC1jdXJyZW50LWJ1ZmZlciAoZ2V0LWJ1ZmZlci1jcmVhdGUg LGJ1ZikNCgkJCSAoZ290by1jaGFyIChwb2ludC1tYXgpKQ0KCQkJIChpbnNl cnQgLHN0ciAiIGF0ICIgKGN1cnJlbnQtdGltZS1zdHJpbmcpICI6ICIpDQoJ CQkgKHBwIGFyZ3MgKGN1cnJlbnQtYnVmZmVyKSkpKSkNCg0KKGFkZC1ob29r ICdwb3N0LWNvbW1hbmQtaG9vayAneC1kZXNjcmliZS1zZWxlY3Rpb25zKQ0K KHNldHEgeC1zZWxlY3Rpb24tdGltZXIgKHJ1bi13aXRoLXRpbWVyIDAgMC4y NSAneC1kZXNjcmliZS1zZWxlY3Rpb25zKSkNCihhZGQtaG9vayAneC1zZW50 LXNlbGVjdGlvbi1ob29rcw0KCQkJCQkocHAtbGFtYmRhICIqWCBTZWxlY3Rp b24gTmV3cyoiICJTZW50IHNlbGVjdGlvbiIpKQ0KKGFkZC1ob29rICd4LWxv c3Qtc2VsZWN0aW9uLWhvb2tzDQoJCQkJCShwcC1sYW1iZGEgIipYIFNlbGVj dGlvbiBOZXdzKiIgIkxvc3Qgc2VsZWN0aW9uIikpDQooYWRkLWhvb2sgJ3gt c2VudC1zZWxlY3Rpb24taG9va3MgJ3gtZGVzY3JpYmUtc2VsZWN0aW9ucykN CihhZGQtaG9vayAneC1sb3N0LXNlbGVjdGlvbi1ob29rcyAneC1kZXNjcmli ZS1zZWxlY3Rpb25zKQ0KDQo7OyBGb3IgdXNlIHdpdGggYGV2YWwtbGFzdC1z ZXhwJw0KOzsgKHgtb3duLXNlbGVjdGlvbi1pbnRlcm5hbCAnQ0xJUEJPQVJE ICJmb28iKQ0KOzsgKHgtb3duLXNlbGVjdGlvbi1pbnRlcm5hbCAnUFJJTUFS WSAiYmFyIikNCjs7ICh4LWRpc293bi1zZWxlY3Rpb24taW50ZXJuYWwgJ0NM SVBCT0FSRCkNCjs7ICh4LWRpc293bi1zZWxlY3Rpb24taW50ZXJuYWwgJ1BS SU1BUlkpDQo7OyAoY2FuY2VsLXRpbWVyIHgtc2VsZWN0aW9uLXRpbWVyKQ0K ---1518306044-1068664010-1093310305=:31548 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ---1518306044-1068664010-1093310305=:31548--