From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Speed of keyboard macro execution? Date: Thu, 10 Dec 2015 19:53:11 +0200 Message-ID: <83lh929omw.fsf@gnu.org> References: <20151209163954.0cefcc7f@jabberwock.cb.piermont.com> <87si3bcltu.fsf@isaac.fritz.box> <20151209180343.5a67c0e7@jabberwock.cb.piermont.com> <83r3iu9rvp.fsf@gnu.org> <20151210120051.6be8201f@jabberwock.cb.piermont.com> <87k2omciy2.fsf@isaac.fritz.box> <20151210123312.39c417c9@jabberwock.cb.piermont.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1449770019 15363 80.91.229.3 (10 Dec 2015 17:53:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Dec 2015 17:53:39 +0000 (UTC) Cc: deng@randomsample.de, emacs-devel@gnu.org To: "Perry E. Metzger" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 10 18:53:28 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a75PD-00019u-Uw for ged-emacs-devel@m.gmane.org; Thu, 10 Dec 2015 18:53:28 +0100 Original-Received: from localhost ([::1]:43496 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a75PD-0002Sd-D0 for ged-emacs-devel@m.gmane.org; Thu, 10 Dec 2015 12:53:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48194) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a75Oz-0002ST-8T for emacs-devel@gnu.org; Thu, 10 Dec 2015 12:53:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a75Ov-0002K5-WE for emacs-devel@gnu.org; Thu, 10 Dec 2015 12:53:13 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:58063) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a75Ov-0002Jv-O7 for emacs-devel@gnu.org; Thu, 10 Dec 2015 12:53:09 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NZ500H00LMXJO00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Thu, 10 Dec 2015 19:53:07 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NZ500HBBLOJBH60@a-mtaout22.012.net.il>; Thu, 10 Dec 2015 19:53:07 +0200 (IST) In-reply-to: <20151210123312.39c417c9@jabberwock.cb.piermont.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:196035 Archived-At: > Date: Thu, 10 Dec 2015 12:33:12 -0500 > From: "Perry E. Metzger" > Cc: Eli Zaretskii , emacs-devel@gnu.org > > On Thu, 10 Dec 2015 18:27:49 +0100 David Engster > wrote: > > Perry E. Metzger writes: > > > I don't know if it was disingenuous or not, but I think that being > > > able to improve performance would not be a bad thing. > > > > No one is claiming that. AFAIK, the very-long-line problem is not > > easy to fix. > > Perhaps it isn't. Looking at the old thread, it seems like the bidi > code is one of the culprits. No, if this is your conclusion, you are not reading it right. The bidi code makes the awfully slow cases slower, but they are awfully, unbearably slow even when bidi is turned off. IOW, in practical terms, bidi didn't change anything in those cases: half the infinity is still infinity. > OTOH, if I read this right and the problem is partially slow > redisplay, I'm wondering why the redisplay code needs to be involved > at all if a long keyboard macro is being run. Perhaps there should > be some way to suspend redisplay, perform the macro, and then > restart it? I have to admit I haven't looked at the code involved > and it might be utterly infeasible. This I can explain. "Redisplay" comes into play not only for actually redrawing the screen, it also comes into play when, e.g., a command moves cursor down, as in C-n. With (the default) line-move-visual mode, Emacs no longer has an easy way of knowing what character is directly below the current one, what with all the variable-pitch fonts and long lines broken between several screen lines. The only way of finding out where is "one visual line down" is to _simulate_ redisplay. IOW, Emacs runs code that does exactly what redisplay does, but without displaying anything; it just accumulates pixel coordinates until it finds itself one visual line down. Any keyboard macro that moves point will at some point invoke this code, because moving point in a variable-pitch multi-font display is a hard problem, and this is even before we consider complications like display properties, overlay strings, embedded images, and the other calamities.