|
From: | David De La Harpe Golden |
Subject: | bug#6774: Cut and paste with C-w/mouse-2 not working? |
Date: | Mon, 02 Aug 2010 22:35:38 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Icedove/3.0.5 |
On 02/08/10 21:59, Chong Yidong wrote:
David De La Harpe Golden<david@harpegolden.net> 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
[Prev in Thread] | Current Thread | [Next in Thread] |