From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.devel Subject: follow-mode: extremely slow in combination with org-mode Date: Mon, 9 Jul 2018 22:12:58 +0200 Message-ID: References: <87zhzvc9km.fsf@tu-berlin.de> <87o9fwkwo4.fsf@tu-berlin.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d79372057096a3ed" X-Trace: blaine.gmane.org 1531167099 30780 195.159.176.226 (9 Jul 2018 20:11:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Jul 2018 20:11:39 +0000 (UTC) Cc: emacs-devel To: Gerald Wildgruber Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 09 22:11:35 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 1fccVS-0007qC-2H for ged-emacs-devel@m.gmane.org; Mon, 09 Jul 2018 22:11:34 +0200 Original-Received: from localhost ([::1]:44202 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fccXX-0003na-FP for ged-emacs-devel@m.gmane.org; Mon, 09 Jul 2018 16:13:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fccWt-0003nV-LF for emacs-devel@gnu.org; Mon, 09 Jul 2018 16:13:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fccWr-0003ka-V6 for emacs-devel@gnu.org; Mon, 09 Jul 2018 16:13:03 -0400 Original-Received: from mail-lf0-x22e.google.com ([2a00:1450:4010:c07::22e]:45162) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fccWr-0003kC-Gr for emacs-devel@gnu.org; Mon, 09 Jul 2018 16:13:01 -0400 Original-Received: by mail-lf0-x22e.google.com with SMTP id m13-v6so16280303lfb.12 for ; Mon, 09 Jul 2018 13:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z0Z28J75Q9n7Wmqmaw3SjJLdhc2UhpuN2D/VIlRSOuw=; b=Q6yaoB+YbZpJL63ABtEI62UOdy/WCwI7Qv+61F7zzM4KZPWHQOVeIMMVYDCCI9xZyD X3TKDXBLfnQEhEhhvczCtKc5ncvTp0a49KG/vTm6wP0tdLXLrnj/fy3eQDAe1nEF/ZqQ yb2xNM/H0vfTLbL5bmEk/+hws+hjcLQYuJtK8K9uUtWGZSgKK9aYGfQNtksXSwNuxlqo 4NOf1z87GdlJss58Cx16jF+cctrZasNyqc0AbevVekW3W3EEeN2YFl6Wz6ie1MGUlPTn CinZLVjIDCYhxVXUL4wqLWup0cLl2ZrLDKzaK3+0rhD5hKoOmoyYY/p5DKIcU64Rq86p y9aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z0Z28J75Q9n7Wmqmaw3SjJLdhc2UhpuN2D/VIlRSOuw=; b=roQuXBSL+dL/ilgSg3bSs1GO3Zmn8DPNxcmZAzmg8eF/IreO711iSQcb45TlBP2HtP hXauUgsm+RbbKPegqPq24UN0mB+7qCAXHKESauJt5zsamaII83ucUZPt0y7FW8m+Bk+L 6unVjIeFL4QQMBXBjYPqQB7aneo34notReWMBJqWmnyh9AoCsNApYz/k23uWo6McXstA B1xLrlDE8k6BqflEapIWomR//TzZNnXOgmEtB0Pvmqj26VJ/OgcmDFjlHvM/0jDrxdAd agY2ItJEAxC3L/GQFrDPqPaDa+ESkU4dHHvzeDm3mDIE2NDbsVSK0s1UpY3vNI5aDhei BhtQ== X-Gm-Message-State: APt69E19nROyvWDTh89cSFxHnxwtpfM/52F0baBeiGgYxzD4BrIYC5Ve US1AtDH6+c/H96CtfGH113Y/RbRcevltWhjuv00= X-Google-Smtp-Source: AAOMgpc6p0gTcMG0XAtZ+9xfQ6eaEr7nvihXtfrmiDhVKHMQlQbfkMD6sziP8dk3q9ibXQS3UO5yEFGY5XsOdI3LkW4= X-Received: by 2002:a19:9646:: with SMTP id y67-v6mr631358lfd.130.1531167179771; Mon, 09 Jul 2018 13:12:59 -0700 (PDT) Original-Received: by 2002:a19:6a0d:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 13:12:58 -0700 (PDT) In-Reply-To: <87o9fwkwo4.fsf@tu-berlin.de> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::22e 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:227179 Archived-At: --000000000000d79372057096a3ed Content-Type: text/plain; charset="UTF-8" Hi! I decided to go to the bottom of this, and had to do some digging, which took a little bit longer than I thought it would do, sorry about the delay. On Wed, Jun 27, 2018 at 6:43 PM, Gerald Wildgruber wrote: > > - Follow-mode is has problems when the width of the windows differ, > > especially if you have long lines that spill over from one window to > > another. I've written a support package to set up side-by-side windows > in a > > pixel-perfect way, https://github.com/Lindydancer/multicolumn -- please > try > > if and see if follow-mode runs more smoothly. > > Actually I use this already! [...] > You just made my day! Can you tell if the function that uses so much of cpu time -- > follow-calc-win-end -- in the form it is now part of new emacs versions, > has any evident problem compared to your own longer version in pre > version 22 emacs? Cf Alan's posting in this thread: > https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00522.html > > The main difference is that the current version handles clipped lines at the end of a window. My original version predates the addition of the UPDATE optional parameter to window-end. Effectively, it calculated window-end plus one. Anyway, it would not work in a modern Emacs where fonts of different heights could be used. The modern version handles clipped lines by repeating a clipped screen line in the next window. This is for two reasons: 1) Lines where only one or a few pixels are displayed would effectively be hidden from users, if they weren't repeated in the next window. 2) When the cursor is placed on a clipped line, Emacs recenters the window, which breaks Follow mode. Instead, Follow mode selects the next window, which is displaying the same line. (Or rather, this is the way it was supposed to work, I just noticed that it is broken in Emacs 26.1 -- the original window is scrolled anyway. I don't know how long it as been broken.) Lines in this context are screen lines, not physical lines. In other words, if you have a long wrapped physical line, the function should return a suitable position inside the line where the next window should start. The follow-calc-win-end function should return window-end plus one if the line isn't clipped, and the beginning of the bottommost screen line if it is clipped. (The patch supplied by Eli doesn't do this, so it won't work -- but I guess its main purpose of the patch was to figure out which parts of the function consume processing power.) So, where do we go from here? First, I noticed that pos-visible-in-window-p can take an argument PARTIALLY that, when non-nil, makes the function provide information about whether or not the position is partially visible. Presumably, it could replace the pixel juggling the current function do. However, if the big time thief is `window-end` with an non-nil UPDATE argument we must either make is faster (at least after self-insert-command) or figure out a way to avoid calling it too often, somehow. Being (somewhat) older and ((hopefully) somewhat) wiser, I wish I had written a test suite for Follow mode, or at least a test protocol. However, Follow mode was written 12 years before work on Ert even had started... Anyway, having a test suite containing all the corner cases would make it easier to try out alternative implementations, and it would prevent us from introducing bugs like the one I just found. I wished I had more time to work on this, but it took me a week just to find the time to write this mail, so clearly I'm not the best candidate at the moment. Sincerely, Anders Lindgren --000000000000d79372057096a3ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!

I decided to go to the b= ottom of this, and had to do some digging, which took a little bit longer t= han I thought it would do, sorry about the delay.


<= div class=3D"gmail_extra">
On Wed, Jun 27, 2018 a= t 6:43 PM, Gerald Wildgruber <wildgruber@tu-berlin.de>= wrote:
> - F= ollow-mode is has problems when the width of the windows differ,
> especially if you have long lines that spill over from one window to > another. I've written a support package to set up side-by-side win= dows in a
> pixel-perfect way, https://github.com/Lindydancer/multicolumn -- please try
> if and see if follow-mode runs more smoothly.

Actually I use this already! [...]

You just made my day!


Can you tell if the function that uses so much of cpu time --
follow-calc-win-end -- in the form it is now part of new emacs versions, has any evident problem compared to your own longer version in pre
version 22 emacs? Cf Alan's posting in this thread:
https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00522.html


The main difference= is that the current version handles clipped lines at the end of a window. = My original version predates the addition of the UPDATE optional parameter = to window-end. Effectively, it calculated window-end plus one. Anyway, it w= ould not work in a modern Emacs where fonts of different heights could be u= sed.

The modern version handles clipped lines by r= epeating a clipped screen line in the next window. This is for two reasons:=

1) Lines where only one or a few pixels are displayed would effectively be= hidden from users, if they weren't repeated in the next window.
<= br class=3D"gmail-Apple-interchange-newline">2) When the cursor is placed o= n a clipped line, Emacs recenters the window, which breaks Follow mode. Ins= tead, Follow mode selects the next window, which is displaying the same lin= e. (Or rather, this is the way it was supposed to work, I just noticed that= it is broken in Emacs 26.1 -- the original window is scrolled anyway. I do= n't know how long it as been broken.)

Lines in= this context are screen lines, not physical lines. In other words, if you = have a long wrapped physical line, the function should return a suitable po= sition inside the line where the next window should start.

The follow-calc-win-end function should return window-end plus one= if the line isn't clipped, and the beginning of the bottommost screen = line if it is clipped. (The patch supplied by Eli doesn't do this, so i= t won't work -- but I guess its main purpose of the patch was to figure= out which parts of the function consume processing power.)
<= br>
So, where do we go from here? First, I noticed that pos-visib= le-in-window-p can take an argument PARTIALLY that, when non-nil, makes the= function provide information about whether or not the position is partiall= y visible. Presumably, it could replace the pixel juggling the current func= tion do. However, if the big time thief is `window-end` with an non-nil UPD= ATE argument we must either make is faster (at least after self-insert-comm= and) or figure out a way to avoid calling it too often, somehow.
=
Being (somewhat) older and ((hopefully) somewhat) wiser, I w= ish I had written a test suite for Follow mode, or at least a test protocol= . However, Follow mode was written 12 years before work on Ert even had sta= rted... Anyway, having a test suite containing all the corner cases would m= ake it easier to try out alternative implementations, and it would prevent = us from introducing bugs like the one I just found.

I wished I had more time to work on this, but it took me a week just to f= ind the time to write this mail, so clearly I'm not the best candidate = at the moment.

Sincerely,
=C2=A0 =C2=A0 = Anders Lindgren

--000000000000d79372057096a3ed--