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

[Drew Adams]

Dunno whether you prefer a new bug report for this or continuing the
saga within a previous bug report.  This is no longer about "No
primary selection", but picking up from the thread of bug #6689, for
background:
 
> > > I still want the ability to select text with the mouse 
> > > and yank it into the same or another Emacs session
> > > (even another session of another Emacs release -
> > > in either direction).
> > 
> > You can have it, if you customize mouse-drag-copy-region to 
> > t, like it was before the changes that broke mouse-2 on Windows.
> 
> Thanks for the info.  Hopefully, when all of the changes are 
> over and done with, and all of the default decisions made, 
> this and any other customizations needed to get back the 
> previous behavior will be documented together (e.g. in NEWS).
> 
> BTW, the doc string for that option doesn't say much about 
> what it does, at least to me.  And the option name doesn't 
> seem terrific either.
 
Have you actually tried it?  No, it does not work, for me at
least in GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of
2010-08-30 on 3249CTO.
 
Even if I set that option to t in both Emacs sessions (and even if both
sessions are of this latest build), the entire selection is not pasted.
 
For each session:
 
emacs -Q
 
M-x set-variable mouse-drag-copy-region RET t RET
 
Select some text (several words) with the mouse using double-click
mouse-1 on one word then mouse-3 on a later word in the text.
 
mouse-2 in the same session will correctly paste the complete selection.
But mouse-2 in the other session pastes only the first word of the
selection.
 
--

<user_grumble>
Not happy.  I sure wish this mouse/keyboard/copy/paste/kill/yank/ stuff
would converge on a fixed point and would be fixed once and for all, so
we could somehow get back the (superior) behavior we had (at least on
Windows) prior to Emacs 24.

For months now we've been promised that at a minimum users would be
able to easily get back the previous behavior.  But all we've seen for
those months is a steady stream of problems.  Admittedly some of those
problems are not directly related to each other - e.g. some are
applicable only to Windows or only to X or only to Mac or only to
xterms or only about the mouse or only about the keyboard or only
about copying or only about pasting or...

But they all seem to be related to the recent f.+ing with Emacs
selection in the name of conforming Emacs to X Window.  We keep
hearing about things having been fixed.  When will it end?

Sure, by trying Emacs 24 we accept that things will be imperfect
temporarily, but I don't recall something so basic being so
variously broken for so long before.   T E S T  before committing?

Even the prodigious, complex, and profound changes made by K. Handa
(and others) to add Unicode support in Emacs 23 did not introduce as
much perturbation to the development builds - far from it.  What's
going on in the current case that makes it so volatile?
</user_grumble>

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-08-30 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'