Re: Issues with X selection handling

[Davis Herring <herring@lanl.gov>]

...Ok, an update; after sending the previous mail, the Emacs sessions
responded to my C-g, albeit rather fitfully.  They eventually decided that
they each owned one selection (the one where I manually grabbed the
clipboard did think it owned CLIPBOARD, and the other thought it (still)
owned PRIMARY)  and that -no one- owned the other.

Checking with an external program revealed that there was no selection of 
either type active.

Both Emacsen recovered with the message "condition-case: Quit", but who
knows which `condition-case' that was.  So I set `debug-on-quit' and
managed to repeat the lock, this time getting a traceback that showed
`x-get-selection-internal' calling `x-sent-selection-hooks'; this caused
an infinite recursion because my selection-reporting code (which obviously
calls `x-get-selection-internal') was on that hook.  The arguments to the
hook function alternated between "CLIPBOARD COMPOUND_TEXT t" and
"CLIPBOARD STRING t".

I don't see how `x-get-selection-internal' could ever call that hook; 
perhaps the traceback merely means that `x-get-selection-internal' was 
blocked and something -else- called the hook?  That would make sense if 
the two Emacs were deadlocked, each waiting for the other's answer before 
giving its own...  Disowning the selections seems to wake up a frozen 
Emacs, which makes sense with the deadlock-ish idea.

Davis Herring

-- 
This product is sold by volume, not by mass.  If it seems too dense or too 
sparse, it means mass-energy conversion has occurred during shipping.