From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: Saving the selection before killing Date: Fri, 20 Jul 2007 08:27:23 +0200 Message-ID: <46A055CB.6060003@swipnet.se> References: <5fmk5pF3bo3fbU1@mid.individual.net> <87hco5xtbv.fsf@jurta.org> <868x9f30fo.fsf@lola.quinscape.zz> <469DDB7C.4090007@swipnet.se> <469F1450.5090002@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1184912894 16427 80.91.229.12 (20 Jul 2007 06:28:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 20 Jul 2007 06:28:14 +0000 (UTC) Cc: Juri Linkov , rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 20 08:28:12 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IBlyE-0007bf-M4 for ged-emacs-devel@m.gmane.org; Fri, 20 Jul 2007 08:28:10 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IBlyD-00011Z-Vk for ged-emacs-devel@m.gmane.org; Fri, 20 Jul 2007 02:28:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IBlyA-0000zF-Hu for emacs-devel@gnu.org; Fri, 20 Jul 2007 02:28:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IBly9-0000z1-3K for emacs-devel@gnu.org; Fri, 20 Jul 2007 02:28:05 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IBly8-0000yy-VF for emacs-devel@gnu.org; Fri, 20 Jul 2007 02:28:04 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IBly8-0008OG-Bs for emacs-devel@gnu.org; Fri, 20 Jul 2007 02:28:04 -0400 Original-Received: from av10-2-sn2.hy.skanova.net ([81.228.8.182]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IBly7-0002sa-3j for emacs-devel@gnu.org; Fri, 20 Jul 2007 02:28:03 -0400 Original-Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id 623FB386C1; Fri, 20 Jul 2007 08:28:01 +0200 (CEST) Original-Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 278B637F6D; Fri, 20 Jul 2007 08:28:01 +0200 (CEST) Original-Received: from husetbladh.homeip.net (81-235-205-78-no59.tbcn.telia.com [81.235.205.78]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id E7C2E37E42; Fri, 20 Jul 2007 08:27:59 +0200 (CEST) User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) In-Reply-To: X-detected-kernel: Linux 2.4-2.6 X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:75149 Archived-At: 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.