[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issues with X selection handling
From: |
Davis Herring |
Subject: |
Re: Issues with X selection handling |
Date: |
Mon, 23 Aug 2004 19:38:54 -0600 (MDT) |
...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.