From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Horsley Newsgroups: gmane.emacs.bugs Subject: Improving X selection? Date: Fri, 12 Oct 2007 10:50:22 -0400 Message-ID: <20071012105022.6c8b174a@tweety> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1192219288 31668 80.91.229.12 (12 Oct 2007 20:01:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 12 Oct 2007 20:01:28 +0000 (UTC) To: bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 12 22:01:18 2007 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IgQcI-0000lZ-N5 for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Oct 2007 21:56:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IgQcC-0001jg-E8 for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Oct 2007 15:56:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IgLqT-000189-KE for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2007 10:50:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IgLqR-000170-Tg for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2007 10:50:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IgLqR-00016x-Oo for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2007 10:50:31 -0400 Original-Received: from users.ccur.com ([66.10.65.2]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IgLqR-0000Rh-Bb for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2007 10:50:31 -0400 Original-Received: from tweety (localhost [127.0.0.1]) by tweety.ccur.com (8.14.1/8.14.1) with ESMTP id l9CEoMYK007841 for ; Fri, 12 Oct 2007 10:50:23 -0400 X-Mailer: Claws Mail 3.0.2 (GTK+ 2.10.14; i386-redhat-linux-gnu) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-Mailman-Approved-At: Fri, 12 Oct 2007 15:56:06 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:16736 Archived-At: 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. Suddenly, life is wonderful! If I notice the last yank just pasted in the wrong selection, all I need to do is run a yank-pop and like magic the selection I actually wanted replaces the nasty one I didn't want :-). 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? Or is an interface change like that too radical? (Or do people even like the idea at all? :-).