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.devel Subject: Re: Improving X selection? Date: Sat, 30 Aug 2008 05:08:29 +0100 Message-ID: <48B8C7BD.2010207@harpegolden.net> References: <20071012105022.6c8b174a@tweety> <874pgtfw1y.fsf@jbms.ath.cx> <4713067D.2060504@swipnet.se> <87fy0cdvr6.fsf@jbms.ath.cx> <471467FF.5070005@swipnet.se> <87vdxy2kwo.fsf@localhorst.mine.nu> <87tzdanllg.fsf@jurta.org> <48B6E420.9090204@harpegolden.net> <48B6EC17.3000205@harpegolden.net> <87d4jss6xv.fsf@localhorst.mine.nu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220069327 702 80.91.229.12 (30 Aug 2008 04:08:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Aug 2008 04:08:47 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 30 06:09:41 2008 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 1KZHmO-0006dx-Ti for ged-emacs-devel@m.gmane.org; Sat, 30 Aug 2008 06:09:41 +0200 Original-Received: from localhost ([127.0.0.1]:39005 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZHlQ-0003GJ-1O for ged-emacs-devel@m.gmane.org; Sat, 30 Aug 2008 00:08:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZHlN-0003GE-AO for emacs-devel@gnu.org; Sat, 30 Aug 2008 00:08:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZHlK-0003Fv-MR for emacs-devel@gnu.org; Sat, 30 Aug 2008 00:08:36 -0400 Original-Received: from [199.232.76.173] (port=41425 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZHlK-0003Fp-IS for emacs-devel@gnu.org; Sat, 30 Aug 2008 00:08:34 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:49910) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KZHlK-0005JY-8u for emacs-devel@gnu.org; Sat, 30 Aug 2008 00:08:34 -0400 Original-Received: from golden1.harpegolden.net (unknown [86.45.10.133]) (using TLSv1 with cipher DHE-RSA-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 ESMTP id A08078089 for ; Sat, 30 Aug 2008 05:08:32 +0100 (IST) User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) In-Reply-To: <87d4jss6xv.fsf@localhorst.mine.nu> X-Enigmail-Version: 0.95.0 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:103244 Archived-At: David Hansen wrote: > > Would it be possible / desirable that emacs kill-ring somehow cooperates > with these tools? > Well, they are somewhat like the kill-ring.... There's no existing standard api* for generally accesing them though AFAIK, and it's not immediately clear to me how you would mesh them if you wanted to. I'm not sure you would want to - I already use the emacs kill-ring (with yank-pop-change-selection set!) AND klipper - you end up over time with a lot of the same snippets on both the klipper menu and the kill ring, but that doesn't matter much at all? If you did want to, it might be more a case of one supplanting the other than meshing i.e. emacs providing general system clipboard history functionality, like watch-all-system-clipboard-changes-and-autoadd-them-to-kill-ring or emacs having a use-system-clipboard-history-as-kill-ring option such that the system pseudo-kill-ring supplants the emacs kill ring Especially the latter is probably not very workable, given emacs' needs (text properties...). The former could work, at least for textual clipboard contents, but is it worth the bother? * FWIW, one can easily extract clipboard history items from KDE 3.x klipper with it's dcop API e.g. at the command-line, dcop klipper klipper getClipboardHistoryMenu - but other clipboard manager daemons presumably don't support that.