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.bugs Subject: bug#6774: Cut and paste with C-w/mouse-2 not working? Date: Mon, 02 Aug 2010 22:35:38 +0100 Message-ID: <4C573A2A.3030007@harpegolden.net> References: <4C55EF50.3080100@alice.it> <4C5645A1.7000500@harpegolden.net> <87y6coby49.fsf@stupidchicken.com> <4C572AE6.7070104@harpegolden.net> <87wrs8ohnp.fsf@stupidchicken.com> 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 1280785122 13324 80.91.229.12 (2 Aug 2010 21:38:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Aug 2010 21:38:42 +0000 (UTC) Cc: 6774@debbugs.gnu.org, Angelo Graziosi To: Chong Yidong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 02 23:38:38 2010 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.69) (envelope-from ) id 1Og2iT-0002Vm-5C for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Aug 2010 23:38:38 +0200 Original-Received: from localhost ([127.0.0.1]:39305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Og2i5-0000Mr-M3 for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Aug 2010 17:38:13 -0400 Original-Received: from [140.186.70.92] (port=59037 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Og2hw-0000JV-Ef for bug-gnu-emacs@gnu.org; Mon, 02 Aug 2010 17:38:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Og2hu-00040b-4V for bug-gnu-emacs@gnu.org; Mon, 02 Aug 2010 17:38:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51515) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Og2hu-00040X-35 for bug-gnu-emacs@gnu.org; Mon, 02 Aug 2010 17:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Og2fy-00026c-RE; Mon, 02 Aug 2010 17:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David De La Harpe Golden Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Aug 2010 21:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6774-submit@debbugs.gnu.org id=B6774.12807849438073 (code B ref 6774); Mon, 02 Aug 2010 21:36:02 +0000 Original-Received: (at 6774) by debbugs.gnu.org; 2 Aug 2010 21:35:43 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Og2fH-000267-CT for submit@debbugs.gnu.org; Mon, 02 Aug 2010 17:35:43 -0400 Original-Received: from harpegolden.net ([65.99.215.13]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Og2fE-000262-Kg for 6774@debbugs.gnu.org; Mon, 02 Aug 2010 17:35:17 -0400 Original-Received: from [87.198.55.208] (87-198-55-208.ptr.magnet.ie [87.198.55.208]) (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 0B24068474; Mon, 2 Aug 2010 22:35:36 +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: <87wrs8ohnp.fsf@stupidchicken.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 02 Aug 2010 17:36:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org 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:39182 Archived-At: On 02/08/10 21:59, Chong Yidong wrote: > David De La Harpe Golden writes: > >> Does your way work properly in a multi-window context on its own, >> though? I suspect not -that it will deactivate-mark on "boring" >> restored active regions (see below) and set the selection to the >> "boring" region, confounding user expectations, because the restored >> region could be non-empty. >> >> The thing is, if you use focus-follows-mouse between frames, or mouse >> autoselect-window between emacs windows, you select_window without >> going through "normal channels", so trying to do _anything_ smart in >> deactivate-mark tends to break - e.g. the mark is being deactivated in >> a window different to the last window bound to the selection. The selx >> branch just forces the selection to a string if it's lazy-bound to a >> window and emacs still owns it on deactivate mark. > > You're right, the window-switching code needs to be able to change the X > selection buffer if switching into a window where there is an active > region. > well, hold on - see the problem report on emacs-devel [1][2], my goal was to _not_ bind the selection to the new buffer of the restored active region on window change, but rather leave it as the old selection, and consider the restored active region "boring" until it changes again, at which point it becomes the selection. Try it between two kate windows both with selected text, say - note how the selection doesn't change depending on which window you're currently in, it depends on the last text the user actively selected. > But with this change, is there any case that my proposal---i.e. saving a > copy before before-change-functions, for deactivate-mark to refer to if > the region ends up empty---would not handle? Assuming that the current > buffer and the active region can only change as a result of a user > command or window switching, those are the only cases that we have to > cover. I'm a bit tired at this stage, sorry, I'm not sure I'm talking sense. The problem is that we may really want the selection bound to something _non-current_, if we don't want it to instantly reflect a restored boring active region as per above. And there's the two-windows-onto-the-same buffer case to consider, that means lazy-binding the selection to a buffer rather than window can't work very well, was the first reason I had for adding the lazy-binding to windows (and extending windows struct to record a per-window mark as well as point...). [1] http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01258.html [2] http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01314.html