Re: Issues with X selection handling

[Davis Herring]

[These experiments conducted on 21.3.1 on GNU/Linux with XFree86.]

On Thu, 19 Aug 2004, Jan D. wrote:

> >  + `x-disown-selection-internal' doesn't seem to do anything.
> 
> Well, it disowns the selection, but it does not call any hooks if that is what
> you mean.  Can you please say what you expected it to do?

I see -- it does disown the selection, but not only are no hooks called
(the docstring for `x-lost-selection-hooks' explicitly says it should be
called), but the entry is not removed from the internal variable
`Vselection-alist'.  This means Emacs (in Lisp) thinks it still owns the 
selection and that it has the value it had before the disownment.

> >  + `x-lost-selection-hooks' is not always executed when one would expect:
> >   - using the mouse to select text in Emacs and then elsewhere seems to 
> > never call the hooks
> 
> I have not been able to reproduce this with the CVS version or 21.3.
> The lost and send hooks are always called, for PRIMARY and CLIPBOARD.
> Can you test the CVS version?

Unfortunately I can't test the CVS version -- at least, not quickly.  
Beyond that I don't know what to say to this, except to try out the 
attached test code (I've updated it somewhat since my prior postings).  
What I'm trying now is running two Emacsen with the same 
continuous-sampling setup, and alternating between them making selections.

They disagree a notable amount of the time, and `x-lost-selection-hooks' 
is never called with PRIMARY as an argument unless the keyboard is used to 
kill text.  Meanwhile CLIPBOARD appears to call the hooks every time.  
Stranger still is that occasionally one Emacs generates messages in the 
other that look like this:

Sent selection at Mon Aug 23 18:57:44 2004: (CLIPBOARD nil nil)
Sent selection at Mon Aug 23 18:57:44 2004: (CLIPBOARD nil nil)
Sent selection at Mon Aug 23 18:57:44 2004: (PRIMARY nil nil)
Sent selection at Mon Aug 23 18:57:44 2004: (PRIMARY nil nil)

The Emacs requesting the selection isn't sending any type with its 
request, apparently; it gets declined, and decides that there is no such 
selection.

As for the mouse-selection, a mouse-drag after a keyboard event doesn't
even call `post-command-hook' until the next event is received (at which
point the hook is called twice); if I mouse-drag, then tap a key, and
-then- select text elsewhere, the lost-hook is called as I expect.  So
there may be a race between the "completion" of the mouse-drag and the
reception of the "selection stolen" event.  This would explain the 
bizarre "keyboard-dependence".

Of course, it seems to me as though the very delay of such "completion"  
of a mouse command is a much worse problem.  Is there some reason for 
this?

> >   - losing the clipboard usually (but not always) calls the hooks

As an unexpectedly final test, aiming to decide this issue, I 
mouse-selected text in one Emacs, then immediately went to the other and 
evaluated Lisp to grab only the clipboard.  Both Emacsen immediately 
froze.  This, I suppose, is a separate issue worthy of consideration.

The CLIPBOARD/PRIMARY asymmetry is surely some sort of indication as to 
the nature of the bug (since there's no real reason for the selections to 
behave differently), but it might be something as trivial as "the first 
event is lost, and that's usually PRIMARY".

> >  + Occasionally, Emacs itself (i.e. xselect.c) seems to miss a
> > notification that it has lost the selection -- I have, once, seen Emacs
> > insist that it owns the clipboard selection despite the fact that other
> > applications are owning and using it.

This must have been the result of manually disowning a selection; I see
now that this isn't a separate issue.

> We really need a solid test case that always fails to be able to find any bug
> in this area.

All these behaviors are pretty deterministic as far as I can tell.  
Hopefully this additional information (and updated testing code) is 
helpful.

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.

testing.el
Description: X Selection Test Code