From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Improving X selection? Date: Sun, 14 Oct 2007 12:29:01 -0400 Message-ID: References: <20071012105022.6c8b174a@tweety> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1192379528 12916 80.91.229.12 (14 Oct 2007 16:32:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Oct 2007 16:32:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tom Horsley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 14 18:31:58 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Ih6Nh-0002OF-Fe for ged-emacs-devel@m.gmane.org; Sun, 14 Oct 2007 18:31:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ih6NZ-00081a-Th for ged-emacs-devel@m.gmane.org; Sun, 14 Oct 2007 12:31:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ih6Kt-00063c-6i for emacs-devel@gnu.org; Sun, 14 Oct 2007 12:29:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ih6Ks-00063O-Ii for emacs-devel@gnu.org; Sun, 14 Oct 2007 12:29:02 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ih6Ks-00063L-C8 for emacs-devel@gnu.org; Sun, 14 Oct 2007 12:29:02 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ih6Kr-0001e9-RE for emacs-devel@gnu.org; Sun, 14 Oct 2007 12:29:01 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1Ih6Kr-0000IO-Ez; Sun, 14 Oct 2007 12:29:01 -0400 In-reply-to: <20071012105022.6c8b174a@tweety> (message from Tom Horsley on Fri, 12 Oct 2007 10:50:22 -0400) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:80849 Archived-At: My question is this: If I were to change the possible return values for the interprogram-paste-function so that it is allowed to return a list of strings, and I modified all the callers so they could expect a list of strings, and I made the whole list get pushed on the kill ring, would such a change likely be accepted? Sure. That can't do any harm. It might also be good to install the rest of your change, rewritten to use that hook: Anyone who attempts to interact with a mix of older (xterm for instance) and newer (gtk apps) with emacs while doing cut & paste operations has undoubtedly noticed the persistent problem of never winding up with the selection you actually want (now that we have some folks using CLIPBOARD and others using PRIMARY). Yes, you can set x-select-enable-clipboard, but all that does is invert the set of incorrect text you get back. I have just implemented a quick hack (definitely not suitable for prime time) to the x-cut-buffer-or-selection-value function. This hack observes when there is more than one "new" selection and goes ahead and pushes the new ones it isn't planning to return to the caller onto the kill ring. But more people would have to study and try it before we could decide on that.