From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.bugs Subject: bug#8869: Unjustified selection time-out Date: Thu, 16 Jun 2011 02:00:31 +0100 Message-ID: <4DF955AF.6080107@harpegolden.net> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1308186085 17140 80.91.229.12 (16 Jun 2011 01:01:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 16 Jun 2011 01:01:25 +0000 (UTC) Cc: Chong Yidong , 8869@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 16 03:01:20 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QX0xT-0001UG-Ot for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jun 2011 03:01:19 +0200 Original-Received: from localhost ([::1]:33452 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QX0xT-0001XP-2L for geb-bug-gnu-emacs@m.gmane.org; Wed, 15 Jun 2011 21:01:19 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:58634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QX0xE-0001XJ-QH for bug-gnu-emacs@gnu.org; Wed, 15 Jun 2011 21:01:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QX0xD-0006jk-L4 for bug-gnu-emacs@gnu.org; Wed, 15 Jun 2011 21:01:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38663) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QX0xD-0006je-D4 for bug-gnu-emacs@gnu.org; Wed, 15 Jun 2011 21:01:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QX0xC-0003Yk-8S; Wed, 15 Jun 2011 21:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David De La Harpe Golden Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Jun 2011 01:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8869 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8869-submit@debbugs.gnu.org id=B8869.130818604113654 (code B ref 8869); Thu, 16 Jun 2011 01:01:02 +0000 Original-Received: (at 8869) by debbugs.gnu.org; 16 Jun 2011 01:00:41 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QX0wr-0003YB-Bd for submit@debbugs.gnu.org; Wed, 15 Jun 2011 21:00:41 -0400 Original-Received: from harpegolden.net ([65.99.215.13]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QX0wp-0003Xx-4i for 8869@debbugs.gnu.org; Wed, 15 Jun 2011 21:00:40 -0400 Original-Received: from [87.198.47.170] (87-198-47-170.ptr.magnet.ie [87.198.47.170]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTPSA id 0CA676839A; Thu, 16 Jun 2011 02:00:32 +0100 (IST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110606 Icedove/3.1.10 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 15 Jun 2011 21:01:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:47219 Archived-At: > E.g. I suspect the new code sometimes thinks there's a "modern clipboard > manager" running when in reality there simply isn't any. What does (x-selection-exists-p 'CLIPBOARD_MANAGER) return on your system? > Or maybe your > delay is much longer than what is used by other applications. Emacs uses 20s delay by default (x-selection-timeout), qt/kde and gtk/gnome apps are about 10s (estimated by watching them on my system, didn't dig the exact timeout figure from their sources) So emacs is waiting twice as long as other apps, but at 10s, I'd still expect the delay in most other apps to be fairly noticeable (for the apps that try to persist at exit at all). Mind you, some other apps' visible/inputoutput windows do disappear at the start rather than end of their wait, though, which might be perceptually hiding the issue. For Qt/KDE apps, watch out for the stderr message "QClipboard: Unable to receive an event from the clipboard manager in a reasonable time" 10 secs after "closing" them. There's also something of an architectural question raised (though might be a bit late to do anything about it given looming pretest, it's not a showstopper): You're seeing the delay when deleting frames - but there might be ways around emacs asking for its clipboard to be saved in such cases a lot of the time: Right now a given emacs frame['s x11 window] is used as the selection owner, AFAIUI. When that frame is to be deleted, emacs asks the clipboard manager (if one is detected) to save. But if it's not the last frame opened via a given terminal/display connection, that is a little wasteful. Emacs doesn't currently keep an extra per-terminal invisible/input-only window lurking (or maybe it does and I just don't know about it) - in contrast AFAICS gtk+ opens a per-process per-display GtkInvisible for owning selections [1][2][3], and Qt probably does something vaguely similar. Emacs could in principle do similar.* Or if we don't want to do something like that, then I suppose the ownership could be "migrated" to another visible frame on that terminal rather than doing that, "just" set selection owner to another living frame, though that could cause some history-keeping clipboard managers to have duplicate entries (though ones I've used do do dupe checking). [1] http://developer.gnome.org/gtk/2.24/GtkInvisible.html [2] http://git.gnome.org/browse/gtk+/tree/gtk/gtkclipboard.c#n451 [3] http://git.gnome.org/browse/gtk+/tree/gtk/gtkinvisible.c#n239 * Well, gtk+ toolkit builds of emacs may wind up with gtk+'s dangling unused and ignored, emacs doesn't use gtk+'s clipboard handling.