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: Selection changes in revno 100822 Date: Sat, 14 Aug 2010 15:31:33 +0100 Message-ID: <4C66A8C5.4040203@harpegolden.net> References: <834oeyv3ww.fsf@gnu.org> <87mxsqyp98.fsf@stupidchicken.com> <83zkwptyij.fsf@gnu.org> <4C66660D.3090603@swipnet.se> <83sk2htp82.fsf@gnu.org> 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 1281796309 12363 80.91.229.12 (14 Aug 2010 14:31:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 14 Aug 2010 14:31:49 +0000 (UTC) Cc: cyd@stupidchicken.com, =?UTF-8?B?SmFuIERqw6Rydg==?= , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 14 16:31:47 2010 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.69) (envelope-from ) id 1OkHly-0006if-D5 for ged-emacs-devel@m.gmane.org; Sat, 14 Aug 2010 16:31:46 +0200 Original-Received: from localhost ([127.0.0.1]:60691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OkHlx-0004xs-FT for ged-emacs-devel@m.gmane.org; Sat, 14 Aug 2010 10:31:45 -0400 Original-Received: from [140.186.70.92] (port=37363 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OkHlr-0004xP-8i for emacs-devel@gnu.org; Sat, 14 Aug 2010 10:31:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OkHlq-0006tm-6h for emacs-devel@gnu.org; Sat, 14 Aug 2010 10:31:39 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:40403) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OkHlo-0006tD-D5; Sat, 14 Aug 2010 10:31:36 -0400 Original-Received: from [87.198.55.170] (87-198-55-170.ptr.magnet.ie [87.198.55.170]) (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 ESMTPSA id 7B314683D1; Sat, 14 Aug 2010 15:31:31 +0100 (IST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Icedove/3.0.5 In-Reply-To: <83sk2htp82.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:128690 Archived-At: > Thanks, this clears up quite a bit of the confusion. So would it be > correct to modify the doc string of x-select-enable-primary to say > this: > > Non-nil means cutting text sets the primary selection. [and pasting (yanking) gets from the primary selection.] > When the value is nil, the primary selection is still set by > selecting the text. > ...if select-active-regions is t As just mentioned elsepost, a third option other than nil and t, 'lazy, for select-active-regions was introduced recently, which means that mouse/shift selections do, but c-spc selections don't immediately, c-spc selections will defer setting primary to C-w/M-w time. I don't like 'lazy. > Why is it important not to touch the kill ring? > Well, if you do that, you break a conceptually straightforward kill-ring<=>clipboard mapping (that makes "turn on cua mode" somewhat useful advice to newbies who want to use C-x/c/v on x11) and pretty much depart from other-x11-app behaviour again. >>> Thanks in advance for helping me become less confused. >> >> It is very confusing. There are special cases depending on how the selection >> was made, and then badly named variables increase the confusion. Not to >> mention trying to handle multiple platforms with differing capabilities. > > It seems to me that on platforms that have only one selection (the > clipboard), selecting text should do nothing by default, while cutting > should set the clipboard. That sounds sensible to me, for the most part (there may be certain platforms that have an "only one selection (the primary)" - think gpm, where the user expectation would in fact be that mere selection of text changes the gpm "selection buffer" (as it is referred to in the gpm manpage) i.e. gpm happens to be more analogous to an x11 primary than an x11 clipboard, unlike the w32 clipboard where users generally do not expect mere selection of text to erase the previous clipboard contents). w32 is the "odd one out" here of the x11/ns/w32 trinity. I was rambling about ways to create an inter-application primary on w32 a while back, which caused you some puzzlement at the time. Both x11 and ns platforms have functional inter-application clipboard/primary/secondary. While other macosx apps may not typically use the latter two, they still work sensibly inter-session on macosx between emacs instances because of the way *step pasteboards work, and on gnustep/x11 they actually work in integrated fashion with x11 apps on the same desktop so long as you use the right pasteboard names, which is neat. > And there should be a variable to > optionally set the clipboard when the text is selected. (Do we > already have such a variable? No, that would be the clipboard-active-regions I've mentioned before. Some might have thought that's what x-select-enable-clipboard does, but, um, it doesn't, for similar reasons to x-select-enable-primary as just outlined by Jan D. However, it used to "symptomatically" for mouse selections only on w32, because mouse selections used to implicitly copy (mouse-drag-copy-region=>t). That "copy" (kill-ring-save), as well as pushing to the kill-ring, called interprogram-cut-function, which set the clipboard when x-select-enable-clipboard is on.