From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: follow-mode: extremely slow in combination with org-mode Date: Sun, 17 Jun 2018 11:13:33 +0000 Message-ID: <20180617111333.GA12093@ACM> References: <87zhzvc9km.fsf@tu-berlin.de> <83r2l7yn52.fsf@gnu.org> <87y3fedgnq.fsf@tu-berlin.de> <838t7ezokb.fsf@gnu.org> <877emx3not.fsf@tu-berlin.de> <83lgbdu8zs.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1529234328 24493 195.159.176.226 (17 Jun 2018 11:18:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 17 Jun 2018 11:18:48 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: Gerald Wildgruber , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 17 13:18:43 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUVhj-0006Bz-JY for ged-emacs-devel@m.gmane.org; Sun, 17 Jun 2018 13:18:43 +0200 Original-Received: from localhost ([::1]:54665 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUVjo-0002zv-UR for ged-emacs-devel@m.gmane.org; Sun, 17 Jun 2018 07:20:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37008) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUVj0-0002zo-Kx for emacs-devel@gnu.org; Sun, 17 Jun 2018 07:20:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUVix-0006kq-Gl for emacs-devel@gnu.org; Sun, 17 Jun 2018 07:20:02 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:60650 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fUVix-0006gz-9W for emacs-devel@gnu.org; Sun, 17 Jun 2018 07:19:59 -0400 Original-Received: (qmail 85468 invoked by uid 3782); 17 Jun 2018 11:19:51 -0000 Original-Received: from acm.muc.de (p5B146C57.dip0.t-ipconnect.de [91.20.108.87]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 17 Jun 2018 13:19:49 +0200 Original-Received: (qmail 12158 invoked by uid 1000); 17 Jun 2018 11:13:33 -0000 Content-Disposition: inline In-Reply-To: <83lgbdu8zs.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:226402 Archived-At: Hello, Eli. On Sun, Jun 17, 2018 at 11:12:39 +0300, Eli Zaretskii wrote: > > From: Gerald Wildgruber > > CC: > > Date: Sun, 17 Jun 2018 08:57:22 +0200 > > - follow-windows-start-end 17606 57% > > - if 17606 57% > > - let 17603 57% > > - let 17603 57% > > - while 17603 57% > > - setq 17599 57% > > - cons 17599 57% > > - cons 17599 57% > > - cons 17599 57% > > - follow-calc-win-end 17591 57% > > - let* 17591 57% > > - if 9229 30% > > + let 1115 3% > > + pos-visible-in-window-p 26 0% > > posn-point 8350 27% > > + window-inside-pixel-edges 12 0% > Alan, why doesn't follow-calc-win-end doesn't just use window-end with > last argument non-nil? AFAU, that should allow you to compute the > result using 1/4 of the processing time you now invest. Why do you > need all the rest in that function? What am I missing? I honestly don't know for sure. But on 2014-04-27 I made a note in my personal log: "In follow-calc-win-end, we check for EOB being visible in the window, rather than being the window-end. There needs to be a comment here about what the last element means." . I wish I could decipher what I meant, then. I think I might have encountered a corner case, where EOB is _inside_ a window, possibly not even the last window, and using window-end failed for some reason. But I think follow-calc-win-end was in the original follow.el written by Anders Lindgren. Maybe, back in the mists of time, window-end didn't work for some reason - maybe it hadn't yet acquired it's UPDATE argument, or something like that. follow-calc-win-end was much longer in Emacs-21.4, and carried the comment "This function is optimized function for speed!". It had got shorter some time up to Emacs-24.5, where it had already started using posn-point. This rewrite was probably this: commit c93b886f957b55df4fe45d986c34242832ec4a28 Author: Chong Yidong Date: Sun Apr 29 09:48:23 2012 +0800 Fix Follow mode's calculation of window ends. * lisp/follow.el (follow-calc-win-end): Rewrite to handle partial screen lines correctly. (follow-avoid-tail-recenter): Minor cleanup. Fixes: debbugs:8390 Why we don't just use window-end, I don't know. Maybe the sequence of people who've modified follow-calc-win-end have all assumed their predecessors understood why a simple window-end wasn't used. If it is something to do with EOB messing things up, maybe we could amend window-end better to handle EOB. Sorry I can't do any more than speculate, here. -- Alan Mackenzie (Nuremberg, Germany).