From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: follow-mode: extremely slow in combination with org-mode Date: Sun, 17 Jun 2018 16:02:26 +0300 Message-ID: <83k1qxtvkt.fsf@gnu.org> 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> <20180617111333.GA12093@ACM> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1529240473 26843 195.159.176.226 (17 Jun 2018 13:01:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 17 Jun 2018 13:01:13 +0000 (UTC) Cc: wildgruber@tu-berlin.de, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 17 15:01:09 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 1fUXIq-0006px-Db for ged-emacs-devel@m.gmane.org; Sun, 17 Jun 2018 15:01:08 +0200 Original-Received: from localhost ([::1]:55256 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUXKw-0000HZ-3g for ged-emacs-devel@m.gmane.org; Sun, 17 Jun 2018 09:03:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50574) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUXKD-0000HJ-H6 for emacs-devel@gnu.org; Sun, 17 Jun 2018 09:02:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUXKA-0002pM-C2 for emacs-devel@gnu.org; Sun, 17 Jun 2018 09:02:33 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUXKA-0002pF-8U; Sun, 17 Jun 2018 09:02:30 -0400 Original-Received: from [176.228.60.248] (port=2536 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fUXK9-0001Wl-Jg; Sun, 17 Jun 2018 09:02:30 -0400 In-reply-to: <20180617111333.GA12093@ACM> (message from Alan Mackenzie on Sun, 17 Jun 2018 11:13:33 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:226403 Archived-At: > Date: Sun, 17 Jun 2018 11:13:33 +0000 > Cc: Gerald Wildgruber , emacs-devel@gnu.org > From: Alan Mackenzie > > 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. OK, thanks for the explanations. Gerald, could you try the following patch to follow-calc-win-end? Please first see if this makes it significantly faster in your use cases, and if so, please run with it for a while and see if there are some adverse effects. (If this is not faster, it isn't worth testing it more.) diff --git a/lisp/follow.el b/lisp/follow.el index fd397c0..c99fc93 100644 --- a/lisp/follow.el +++ b/lisp/follow.el @@ -925,14 +925,17 @@ follow-calc-win-end the last fully-visible line in WIN. END-OF-BUFFER is t when EOB is fully-visible in WIN. If WIN is nil, the selected window is used." - (let* ((win (or win (selected-window))) - (edges (window-inside-pixel-edges win)) - (ht (- (nth 3 edges) (nth 1 edges))) - (last-line-pos (posn-point (posn-at-x-y 0 (1- ht) win)))) - (if (pos-visible-in-window-p last-line-pos win) - (let ((end (window-end win t))) - (list end (pos-visible-in-window-p (point-max) win))) - (list last-line-pos nil)))) + (or win (setq win (selected-window))) + (with-selected-window win + (let* ((wend (window-end win t)) + (endp (= wend (point-max)))) + (and (> wend (point-min)) + (setq wend (1- wend))) + (setq wend + (save-excursion + (goto-char wend) + (line-beginning-position))) + (list wend endp)))) (defun follow-calc-win-start (windows pos win) "Determine the start of window WIN in a Follow mode window chain.