Subject: bug#6956: 24.0.50; pasting mouse selection in other session pastes only first word

From: David De La Harpe Golden <[email-masked]>
Date: Sat, 04 Sep 2010 21:35:28 +0100

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...