bug#8996: Set PRIMARY from last selection, not last selected window

[Stefan Monnier]

>> Erk. Sorry, yes, this AFAIK sounds like a known (to some people...)
>> problem that is apparently still present in at least some
>> circumstances. I actually meant to check if it was still occurring
>> after the customization vs. binding thing was decided and if so file
>> it as a bug.
>> 
>> I had previously mentioned the subtlety under #6774 (at least) [1],
>> and ISTR Chong Yidong also being aware of it, though I'm having some
>> trouble finding the relevant email, so hopefully I'm not unjustly
>> saying that.

> I can't reproduce this bug with Metacity with focus-follows-mouse on.
> I'm surprised this issue has reappeared; the whole point of the current
> active selection implementation is that Emacs grabs the primary
> selection only after executing a command (in the command loop).  Simply
> switching to an Emacs frame should not trigger it---could it be that
> your Emacs is customized to do something funky with the command loop?

Here's my recipe with no funky anything (just plain old trunk):

% trunk/src/emacs -Q
C-x 2
M-: (setq mouse-autoselect-window t) RET
Select a word with a double-mouse-1 click on a word in one of the two windows.
Move the mouse over the other window and then outside Emacs frame to an xterm.
Hit mouse-2 in the xterm.

In my case, the mouse-2 does not paste the selected word but the other
part of the buffer that happened to be the selected region in the
other window.

The window manager is ctwm rather than Metacity, in case it matters.


        Stefan