From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: X selections and multi tty Date: Thu, 26 May 2011 18:49:12 -0400 Message-ID: <87hb8h2i3b.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1306450163 22441 80.91.229.12 (26 May 2011 22:49:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 26 May 2011 22:49:23 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 27 00:49:20 2011 Return-path: Envelope-to: ged-emacs-devel@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 1QPjMl-0001bT-5l for ged-emacs-devel@m.gmane.org; Fri, 27 May 2011 00:49:19 +0200 Original-Received: from localhost ([::1]:60620 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QPjMk-000320-Nu for ged-emacs-devel@m.gmane.org; Thu, 26 May 2011 18:49:18 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55215) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QPjMi-00031k-3I for emacs-devel@gnu.org; Thu, 26 May 2011 18:49:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QPjMh-0004WK-4o for emacs-devel@gnu.org; Thu, 26 May 2011 18:49:16 -0400 Original-Received: from vm-emlprdomr-04.its.yale.edu ([130.132.50.145]:59924) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QPjMh-0004W7-31 for emacs-devel@gnu.org; Thu, 26 May 2011 18:49:15 -0400 Original-Received: from furball (dhcp128036226147.central.yale.edu [128.36.226.147]) (authenticated bits=0) by vm-emlprdomr-04.its.yale.edu (8.14.4/8.14.4) with ESMTP id p4QMnDWH013084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 26 May 2011 18:49:13 -0400 Original-Received: by furball (Postfix, from userid 1000) id E4CD4160665; Thu, 26 May 2011 18:49:12 -0400 (EDT) X-Scanned-By: MIMEDefang 2.71 on 130.132.50.145 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.132.50.145 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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 Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139744 Archived-At: I'm doing a cleanup of xselect.c, and came across something puzzling. AFAIU, clipboards and other X selections are per-X-server, which corresponds to terminal objects in Emacs (or close enough; each terminal corresponds to an X display opened by XOpenDisplay). Emacs currently uses a global variable, Vselection_alist, to keep track of what X selections it controls. This seems incorrect, and OTOH it should lead to funky behavior when you use the same Emacs session on two different X servers. For instance, Emacs might own the clipboard on two X servers simultaneously; when it receives a SelectionClear on one, it will act as though it's lost the clipboard period---when in fact the second X server still think Emacs owns the clipboard. The obvious solution seems to be to change Vselection_alist into a terminal-local variable. However, there exists this code in x_handle_selection_clear: /* If the new selection owner is also Emacs, don't clear the new selection. */ BLOCK_INPUT; /* Check each display on the same terminal, to see if this Emacs job now owns the selection through that display. */ for (t_dpyinfo = x_display_list; t_dpyinfo; t_dpyinfo = t_dpyinfo->next) if (t_dpyinfo->terminal->kboard == dpyinfo->terminal->kboard) { Window owner_window = XGetSelectionOwner (t_dpyinfo->display, selection); if (x_window_to_frame (t_dpyinfo, owner_window) != 0) { UNBLOCK_INPUT; return; } } UNBLOCK_INPUT; This contradicts what I thought: it assumes that if Emacs owns the selection on a different display, it doesn't need to relinquish ownership of the selection. Anyone know what's going on?