|
From: | David De La Harpe Golden |
Subject: | bug#6956: 24.0.50; pasting mouse selection in other session pastes only first word |
Date: | Sat, 04 Sep 2010 21:35:28 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100805 Icedove/3.0.6 |
On 04/09/10 20:09, Chong Yidong wrote:
I'd rather not introduce another variable here. I don't object to allowing mouse-save-then-kill obey mouse-drag-copy-region (the emphasis being on the "mouse" rather than the "drag"), provided the doc of mouse-drag-copy-region is updated accordingly.
I had an initial stab (not bothering with "double" previously mentioned, guess there's no demand) that I was about to send, but then I realised my effort was inadequate, so just to note:
We _don't_ want a new kill ring entry for each new mouse-3 click in a different position for a given region activation, we want it to replace the front of kill-ring if it's extending a region that's already been saved to the kill ring previously in the same activation.
Testing emacs 22.3, it replaced, and as a comment in its (too different to use directly) source says:
;; We have already put the old region in the kill ring. ;; Replace it with the extended region. ;; (It would be annoying to make a separate entry.)- having just tried a patch that didn't take pains to do that replacement, I can confirm it is annoying...
=========Aside: If someone were to make mouse-3 dragging extend an existing region some day*, of course you wouldn't want it copying to kill ring a zillion times. Maybe mouse-3-drag-existing-region-adjustment could be added "cheaply" by reusing most of the existing mouse-drag.
* analogous with other-app Shift-Mouse-1 dragging, emacs of course having some popup font menu on Shift-Mouse-1 and using Mouse-3 for existing region adjustment where other apps tend to have a popup context menu on Mouse-3 and use Shift-Mouse-1 for existing region adjustment...
[Prev in Thread] | Current Thread | [Next in Thread] |