GNU bug report logs - #6774
Cut and paste with C-w/mouse-2 not working?

Previous Next

Full log

View this message in rfc822 format

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 6774 <at> debbugs.gnu.org, Angelo Graziosi <angelo.graziosi <at> alice.it>
Subject: bug#6774: Cut and paste with C-w/mouse-2 not working?
Date: Mon, 02 Aug 2010 22:35:38 +0100

On 02/08/10 21:59, Chong Yidong wrote:
> David De La Harpe Golden<david <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.