Re: Saving the selection before killing

[Stefan Monnier]

>>> Search for klipper in etc/PROBLEMS.  Now this proposal will make Emacs
>>> behave like a buggy klipper.
>> Not at all.  The bug in the klipper was that it requested the selection
>> over and over.  My code only causes the selection to be requested when it
>> shifts from being owned by some other app to being owned by Emacs.
>> I.e. there's no looping involved.

> Looping was only part of the problem.  Large selection was also a factor.

I see no evidence that someone would have noticed something if it
weren't looping.

> If Emacs will request large selections from other programs, they can
> become sluggish too.

They'll be temporarily busy replying to Emacs just at those moments when you
do a kill in Emacs (not all kills, of course).  That is a far cry from
"become sluggish".

>>> I'd be annoyed to see that in my kill ring.
>> Please try it before jumping to conclusions.

> I did try it.  Open up an OO document with some pages, select all text in
> the document.  Move to Emacs, kill some text, C-y, M-y.  I get the OO
> document pasted as a big chunk of text.

Yes, that's the expected behavior.  Which part is *annoying*?
Another M-y will get you to the next kill-ring element.
The same thing could have happened without my patch if you happened to have
killed a big chunk of text in the past.

> Pasting the selection from other applications into Emacs (or any other
> application) over a slow link is already a problem.  This would make
> it worse.

That could be.  AFAIK, this is the only serious objection you have.


        Stefan


PS: You don't need a slow link: just take a local application, select
something in it, then suspend it, then go to Emacs and try to do C-y (or
C-k with my patch).