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

[Drew Adams]

> > A user in Emacs 20, 21, 22, 23 could have 
> > `mouse-drag-copy-region' nil, and thus
> > not have mouse selection touch the kill ring - in principle 
> > (even if not in fact, because of a bug), and yet s?he was
> > still able to select and paste using the mouse - between
> > sessions, including sessions with different Emacs versions.

Question: was that bug only on Windows? Could users on X window set the var to
nil and mouse-select + pasted between sessions? If so, then this is a regression
not only in principle but in fact, i.e. wrt actual behavior, not only intended
behavior.

> > That ability is lost. This is a regression wrt the 
> > advertised behavior for Emacs 22 through 23 (ever since
> > that user option has existed).
> 
> It isn't a regression on Windows, see below.  This thread was, at
> least for me, only about w32.

Why not check what the behavior pre-Emacs 24 was on non-Windows? If users could
select+paste between sessions without affecting the kill ring before, and they
cannot now, then this is not only about w32.

> > IOW, you seem to be just pointing out that there was an 
> > Emacs 22/23 bug here, in that `mouse-drag-copy-region' polluted
> > the kill ring even when it was nil.
> 
> It's not a bug, it's how mouse selections work in Emacs: text gets to
> the clipboard as a side effect of being put on the kill ring.  It has
> always been like that, at least on Windows, in Emacs 23 and before, as
> in Emacs 24.

Forget about Windows. What's the behavior in X window? And what was it before
Emacs 24? Have users lost an ability to mouse-select + paste between sessions
without affecting the kill ring?

> > Not the intended, advertised behavior, but a buggy behavior.
> > `mouse-drag-copy-region' was a no-op option.
> 
> That is a completely different issue.  mouse-drag-copy-region was not
> a no-op only on X, where there's the PRIMARY selection in addition to
> the clipboard.  Unless users of X are concerned about this change, I'm
> not going to be.

If it is a bug on X then it needs to be fixed on X and Windows. Your attitude
seems to be: (a) you don't know or care about X, and (b) it never worked right
on Windows anyway, so (c) it's not a bug. The attitude should be: (a) it doesn't
work right on Windows, (b) if it used to work on X then if it doesn't work now
on X then there is an X bug, and (c) in that case it should also be fixed to
work on Windows.

> > That new bug is the one I reported: "pasting mouse selection in
> > other session".
> 
> That bug is solved, whether you like it or not, in exactly the way you
> wanted: by having an option (that fortunately already existed) one
> needs to customize.

The bug is not solved if it still doesn't work in the case where mouse selection
does not copy to the kill ring.

Again, I personally will probably let mouse selection copy to the kill ring, so
this is not about what I will use. And no, I don't care to argue about it just
for the heck of it. I think there might well be a loss of a user feature here.
On Windows there is not, in actuality, because it never worked properly. But on
X? Were users able to mouse-select and mouse-paste between sessions without
first copying to the kill ring?

More generally, if you can mouse-select+paste within an Emacs session without
affecting the kill ring, why shouldn't you be able to do that between sessions?
Seems natural, no?