emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Saving the selection before killing


From: Jan Djärv
Subject: Re: Saving the selection before killing
Date: Fri, 20 Jul 2007 08:27:23 +0200
User-agent: Thunderbird 2.0.0.4 (Macintosh/20070604)



Stefan Monnier skrev:
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.


You obviously haven't run Emacs over a slow (well say less than 1 Mbit/s) ssh forward X connection.

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".

Selections over slow links are painful right now. Emacs 22 is so much slower in this regard than 21.x. For example, single click with mouse-1 sometimes makes Emacs loop forever (C-g works though), redisplay for small changes can take 10:s of seconds, popup of tool tip also takes several seconds. Your proposal should be customizable, and preferrably default off, as it is a new behaviour.


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*?

That when that amount of text gets drawn over a slow link it takes time. And that when Emacs redisplays, it takes time. We are talking 10:s of seconds here.

Another M-y will get you to the next kill-ring element.

Yes, but I have to wait several seconds before Emacs is responsive again.

The same thing could have happened without my patch if you happened to have
killed a big chunk of text in the past.

But then I would know it was in the kill ring.

        Jan D.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]