From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stuart D. Herring" Newsgroups: gmane.emacs.devel Subject: Re: [EPeterson@mcdonaldbradley.com: Kill ring leak in winemacs macros] Date: Thu, 18 Aug 2005 15:17:25 -0700 (PDT) Message-ID: <45217.128.165.123.83.1124403445.squirrel@webmail.lanl.gov> References: <34161.128.165.123.83.1123097221.squirrel@webmail.lanl.gov> <42F1208D.1070307@student.lu.se> <34340.128.165.123.83.1123102769.squirrel@webmail.lanl.gov> <40280.128.165.123.83.1124204823.squirrel@webmail.lanl.gov> <43020FDF.6060007@gnu.org> <430211FD.5000507@gnu.org> Reply-To: herring@lanl.gov NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1124404674 22814 80.91.229.2 (18 Aug 2005 22:37:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 18 Aug 2005 22:37:54 +0000 (UTC) Cc: Eric Peterson , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 19 00:37:50 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1E5szo-00054G-RH for ged-emacs-devel@m.gmane.org; Fri, 19 Aug 2005 00:36:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E5t3M-0007BY-4u for ged-emacs-devel@m.gmane.org; Thu, 18 Aug 2005 18:40:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1E5sxs-0005iD-KV for emacs-devel@gnu.org; Thu, 18 Aug 2005 18:34:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1E5sxW-0005ZK-Hx for emacs-devel@gnu.org; Thu, 18 Aug 2005 18:34:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E5sxT-0005Pi-Ak for emacs-devel@gnu.org; Thu, 18 Aug 2005 18:34:00 -0400 Original-Received: from [192.65.95.54] (helo=mailwasher-b.lanl.gov) by monty-python.gnu.org with esmtp (Exim 4.34) id 1E5sxX-0004Pl-3C; Thu, 18 Aug 2005 18:34:03 -0400 Original-Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailwasher-b.lanl.gov (8.12.11/8.12.11/(ccn-5)) with ESMTP id j7IMHUXu023336; Thu, 18 Aug 2005 16:17:30 -0600 Original-Received: from webmail1.lanl.gov (webmail1.lanl.gov [128.165.4.106]) by mailrelay1.lanl.gov (8.12.11/8.12.11/(ccn-5)) with ESMTP id j7IMHPvn023274; Thu, 18 Aug 2005 16:17:25 -0600 Original-Received: from webmail1.lanl.gov (localhost.localdomain [127.0.0.1]) by webmail1.lanl.gov (8.12.11/8.12.11) with ESMTP id j7IMHP84001351; Thu, 18 Aug 2005 16:17:25 -0600 Original-Received: (from apache@localhost) by webmail1.lanl.gov (8.12.11/8.12.11/Submit) id j7IMHPSM001347; Thu, 18 Aug 2005 15:17:25 -0700 X-Authentication-Warning: webmail1.lanl.gov: apache set sender to herring@lanl.gov using -f Original-Received: from 128.165.123.83 (SquirrelMail authenticated user 196434) by webmail.lanl.gov with HTTP; Thu, 18 Aug 2005 15:17:25 -0700 (PDT) In-Reply-To: Original-To: "Jason Rumney" User-Agent: SquirrelMail/1.4.4-2 X-Priority: 3 (Normal) Importance: Normal X-PMX-Version: 4.7.1.128075 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:42249 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:42249 > I'm still not convinced this change is worth making now. On X, even > with clipboard enabled, the actual copying to the clipboard is only > performed if another application requests it. Andrew Innes suggested > many years ago that the W32 clipboard should work the same way, but > noone has picked up that job yet. I don't know which way Mac does it, > but that can probably be modified to use delayed copying if it does > not already. So we are talking about reducing the functionality of > keyboard macros to get around a performance problem that does not > exist on the most important platforms, and that we know can be fixed > on others. The performance problem is entirely secondary (if it even exists); this is a correctness problem. Consider a macro like, say, this: C-e C-w C-f C-y C-s . RET (which would shuffle chunks of lines around based on periods). Now set it running enough times to take, say, 15 minutes of real time (unlikely for a macro this simple, but just suppose). While waiting you naturally want to do something else; you switch into Firefox and do some searches on the emacs-devel archives. Finding a neat phrase to search for, you copy it. Unbeknownst to you, Emacs had just finished doing `forward-char' and was about to do `yank', which then gets your search string instead of whatever was killed last. Now your text is corrupted, possibly irreversibly (if the change falls off the end of the undo list and the mark ring before you can try to recover it). Moreover, it's quite likely that before you can paste your text, Emacs loops around and kills some more text; your copy/paste in Firefox has also been broken. Sorry if this is belaboring the point too much; I just wanted to explain what the original issue really was. That said: Eric Peterson (the bug reporter) did also say that macros seemed slower on W32 than on some Unix system, and attributed it to the actual data-copying. I don't know if the slowdown is real, or if the clipboard is to blame. However, I don't see how copying on W32 (to the clipboard) can be made any faster, since the W32 clipboard functions much like the old X cut buffers and is actually real data storage on the part of the window system. I don't think there's a way to only interact with it "when you have to", but I could be wrong. Davis Herring PS - Eric Peterson is cc'ed on this email in case he doesn't know the issue is being resolved. Eric: there are several ways to fix this (emacs-devel is currently deciding among them), and it should be a customizable option in the next version of Emacs. Until then, here's two workarounds (put them in your .emacs or so, bind keys to them, whatever). The first function is self-contained and more convenient, but if you have some reason to avoid recursive edits, use the rest of it all together. Note that the "real" fix may look nothing like this! (defun private-kills-recursive-edit () "Disable interprogram cut and paste and do a recursive edit. When the recursive edit finishes, any new text available from the window system will be available for yanking." (interactive) (let (interprogram-cut-function interprogram-paste-function) (recursive-edit))) (defvar suspended-interprogram-functions nil "\"Real\" interprogram functions, as a cons: (CUT . PASTE).") (defun suspend-interprogram-kills () "Disable interprogram cut and paste (temporarily). It can be re-enabled with `resume-interprogram-kills'." (interactive) (if suspended-interprogram-functions (error "Interprogram kills already suspended") (setq suspended-interprogram-functions (cons interprogram-cut-function interprogram-paste-function) interprogram-cut-function nil interprogram-paste-function nil))) (defun resume-interprogram-kills () "Undo `suspend-interprogram-kills'. Any new text available from the window system becomes available for yanking." (interactive) (if suspended-interprogram-functions (setq interprogram-cut-function (car suspended-interprogram-functions) interprogram-paste-function (cdr suspended-interprogram-functions) suspended-interprogram-functions nil) (error "Interprogram kills not suspended"))) -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping.