Re: Problem copying large text under X

[Jan D.]

Kim F. Storm wrote:
> "Jan D." <address@hidden> writes:
>
>
> > > After a (long) while, it does seem to terminate the clipboard protocol
> > > and things are back to normal performance.
> > >
> > > It could seem like the clipboard program (KDE klipper) is slow,
> > > but it does seem to get the whole data eventually.
> >
> > FWIW, klipper on KDE 3.3 does not seem to have this problem, it
> > completes almost instantly.
>
>
> So does it here -- but it seem to immediately requst the same selection
> again.  Actually this happens even if I just copy 3 bytes with M-w.
>
> Here's output when I enable TRACE_SELECTION in xselect.c
...
> 6469: Sending all 76 bytes
> 6469: Sending all 3 bytes
...
> 6469: Sending all 76 bytes
> 6469: Sending all 3 bytes
>
> etc. etc. etc.
>
> So copying to the clipboard works fin -- it just sends it again
> forever, because it's asked to do so!!!
>
> Look very much like a bug in klipper, but parhaps there's a way
> to make it stop.
>
> Here's the trace for the full xdisp.c [there's additional trace output
> that I added, but I suppose you get the picture].
...
> etc. etc. ad infinum.


Thanks, I know now what happens.  The X selection mechanism where designed so 
that transfer between X clients should only happen when needed, i.e. one client 
wanted the selection data.  If no client asks for selection data, the X server 
simply keeps track of the owner of the selection data (not the data itself), 
and informs other clients when the owner changes.  Programs like klipper goes 
against this design, in that they wish to transfer the selection data everytime 
it changes regardless of anyone who uses klipper asked for it.  It would be one 
thing if they got the selection data and then became the owner of the 
selection, but they don't, the owner is still the original client (Emacs).

Here is where klipper runs into trouble, there is no X protocol request that 
tells klipper if Emacs has changed the selection data (another part of text is 
selected for example).  The owner is still Emacs, so from an X point of view, 
nothing has changed.  So to figure out if the selection data is the same, 
klipper polls Emacs.  I've looked at the source, in kde 3.1.5 klipper gets the 
whole selection data (the whole xfns.c file in this case) every second and 
compares that with the previous request.  In more recent kde (like 3.3), 
klipper instead of getting the whole selection data just gets the TIMESTAP of 
the selection (4 bytes), and compares the timestamps instead.  Hence, 3.3 is so 
much faster, but there is still polling as you discovered.

I don't see any Emacs bug here, nor any way to stop klipper from polling (I 
didn't find any configuration option in klipper for this).

> I think I have found various problems in the synchronization and
> queuing of event between xterm.c, keyboard.c, and xselect.c, but
> fixing those problems don't fix this problem.

Unfortunately no.

        Jan D.