From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Selection changes in revno 100822 Date: Sat, 14 Aug 2010 11:00:04 +0300 Message-ID: <83zkwptyij.fsf@gnu.org> References: <834oeyv3ww.fsf@gnu.org> <87mxsqyp98.fsf@stupidchicken.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1281772945 1685 80.91.229.12 (14 Aug 2010 08:02:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 14 Aug 2010 08:02:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 14 10:02:21 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 1OkBh5-0003P7-O8 for ged-emacs-devel@m.gmane.org; Sat, 14 Aug 2010 10:02:20 +0200 Original-Received: from localhost ([127.0.0.1]:36466 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OkBh5-00021E-3z for ged-emacs-devel@m.gmane.org; Sat, 14 Aug 2010 04:02:19 -0400 Original-Received: from [140.186.70.92] (port=53540 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OkBgx-000219-60 for emacs-devel@gnu.org; Sat, 14 Aug 2010 04:02:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OkBgv-0004Zx-7b for emacs-devel@gnu.org; Sat, 14 Aug 2010 04:02:11 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:35400) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OkBgv-0004Zs-1N for emacs-devel@gnu.org; Sat, 14 Aug 2010 04:02:09 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0L7400500U8ID000@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 14 Aug 2010 11:02:07 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.126.102.143]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L740043RUBIKNC0@a-mtaout22.012.net.il>; Sat, 14 Aug 2010 11:02:07 +0300 (IDT) In-reply-to: <87mxsqyp98.fsf@stupidchicken.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:128663 Archived-At: > From: Chong Yidong > Cc: emacs-devel@gnu.org > Date: Fri, 13 Aug 2010 21:08:51 -0400 > > Eli Zaretskii writes: > > Thanks for looking through the changes. > > > . Why was mouse-drag-copy-region changed to default to nil? This > > variable doesn't seem to be related to selections, but rather to > > the kill ring. > > IIRC, this was part of the attempt to cut down on the special casing > involved in mouse drags. It is not consistent with shift-selection, for > instance. Perhaps we should solve this inconsistency the other way around: have shift-selected text be copied (under control of the same variable). But that is unrelated to the main issue of this thread; I personally have no problems with the new default. > > . The change in binding mouse-2 to mouse-yank-primary instead of > > mouse-yank-at-point, in addition to referencing only the primary > > selection, means one more change: mouse-2 no longer yanks the last > > kill, except through the primary selection. Is this change in > > behavior intentional, and if so, what is the reason behind this > > change? > > I assume you mean mouse-yank-at-click. Yes, sorry. > The change is intentional. The > standard behavior of other X applications is for mouse-2 to insert > primary. mouse-yank-at-click calls yank, but since > x-select-enable-primary is now nil, that does not insert primary. I'm utterly confused now. The doc string of x-select-enable-primary says: Non-nil means cutting and pasting uses the primary selection. According to this, the value of nil, the current default, means "cutting and pasting do NOT use the primary selection", right? But OTOH, the NEWS entry says something contradictory: The way Emacs interacts with the clipboard and primary selection, by default, is now similar to other X applications. In particular, kill and yank use the clipboard, in addition to the primary selection. The last sentence seems to say that kill and yank still do use the primary selection, and _in_addition_ also use the clipboard. If that's the intent of this text, then it seems to be in contradiction with the new default of x-select-enable-primary. OTTH (On The Third Hand), mouse-2 is one way of pasting (yanking) text that was cut (killed) elsewhere. And the new binding of mouse-2 to mouse-yank-primary _does_ insert text from the primary selection, albeit by a different way. IOW, mouse-2 works _against_ the value of x-select-enable-primary. It also seems to be in contradiction with the NEWS entry, in that it doesn't access the clipboard (unless I'm missing something). How to reconcile these apparent contradictions? What exactly is the role of x-select-enable-primary, if Emacs does not behave according to its value and its advertised doc string? Do we still want to have kill/yank and cut/paste be largely synonyms? If so, they are now a tad less synonyms, so it seems, as at least one commonly used command does paste, but does not yank. Please also note that x-select-enable-primary exists only on X, but the changes we are discussing affect all builds, which just adds to confusion on those builds that do not use X. See below for one such example. > We could change mouse-yank-primary so that it calls yank if no primary > selection exists. But maybe that is too confusing. This is directly relevant to the issue at (my) hand: how to restore the expected behavior of selections on Windows. If it is okay to call `yank' when there's no primary selection, then that's one way of fixing the bug on Windows. But then note that `yank' does not only insert text, it also does other non-trivial things to the kill ring etc.; so if the primary selection _does_ exist, all those things won't be done. This is unlike the old code, which accessed the selection from inside `yank', and then treated it in the same way as if it came from the kill ring. An alternative way of fixing the bug on Windows would be to modify the Windows implementation of x-get-selection to get the text from the clipboard if the (emulated) primary selection does not exist. Which of these ways is the best one, depends on clearing up the above confusions. You say "maybe [calling yank] is too confusing" -- what kind of confusion do you envision here? One other issue we should consider IMO is what is the semantics of mouse-2 in sessions that support the mouse, but cannot access selections. One such example is a TTY with a GPM mouse. I don't have access to such a build of Emacs, but I'm quite sure mouse-2 there will either do nothing or signal an error. That's hardly a good thing, because previously it would yank from the kill ring. Thanks in advance for helping me become less confused.