From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#16129: 24.3.50; Emacs slow with follow-mode when buffer ends before last window Date: Fri, 10 Jan 2014 11:31:49 +0200 Message-ID: <83vbxsb2t6.fsf@gnu.org> References: <83bnzpu622.fsf@gnu.org> <8338l1t6ip.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1389346331 20378 80.91.229.3 (10 Jan 2014 09:32:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jan 2014 09:32:11 +0000 (UTC) Cc: 16129@debbugs.gnu.org To: Anders Lindgren Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 10 10:32:17 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1W1YRs-0000lk-7R for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jan 2014 10:32:16 +0100 Original-Received: from localhost ([::1]:55984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1YRr-0006lG-QR for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jan 2014 04:32:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48143) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1YRj-0006kz-MX for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 04:32:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1YRe-0002Gw-Gk for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 04:32:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58935) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1YRe-0002Gp-Cr for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 04:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W1YRd-0008Bw-Mp for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 04:32:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Jan 2014 09:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16129 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16129-submit@debbugs.gnu.org id=B16129.138934631831477 (code B ref 16129); Fri, 10 Jan 2014 09:32:01 +0000 Original-Received: (at 16129) by debbugs.gnu.org; 10 Jan 2014 09:31:58 +0000 Original-Received: from localhost ([127.0.0.1]:44721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1YRY-0008Bc-Ru for submit@debbugs.gnu.org; Fri, 10 Jan 2014 04:31:57 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:52351) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1YRU-0008BI-JB for 16129@debbugs.gnu.org; Fri, 10 Jan 2014 04:31:54 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MZ600A00IELJF00@a-mtaout23.012.net.il> for 16129@debbugs.gnu.org; Fri, 10 Jan 2014 11:31:50 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ600ABZIH2FY60@a-mtaout23.012.net.il>; Fri, 10 Jan 2014 11:31:50 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:83226 Archived-At: > Date: Tue, 7 Jan 2014 09:13:19 +0100 > From: Anders Lindgren > Cc: Stefan Monnier , 16129-done@debbugs.gnu.org > > Thanks, I tried it out on the trunk, and it seems to be working correctly! Thanks for testing. > I'm open to reimplementing follow-mode in another way, if you think that > it's necessary. However, there are two different uses of set-window-start, > and maybe we don't need to change both: > > * Normally, when the position of the active window change, the start of the > other windows are updated. This occurs very infrequent, and it would > require a redisplay anyway. > * When a window shows the empty tail of a buffer, point-max is "hammered" > into window-start to ensure that the display engine doesn't recenter the > window. > > Of the two uses, I only consider the second a problem. I think we should consider both, because they both are detrimental to the efficiency of redisplay. You see, the Emacs redisplay has a very complex problem to solve, because there are a gazillion of ways to change some obscure Lisp data structure that can potentially change what should be on the glass. However, if redisplay needed to examine all those potential changes and decide whether they actually change the displayed portion of the buffer, redisplay would become painfully slow. So we have a lot of optimizations in the display engine, each of which basically says: if none of the following events happened since last redisplay cycle, then this and that potential changes don't need to be considered. Each optimization comes with a list of events that invalidate it. Redisplay basically tries to apply each optimization in sequence, starting from the most aggressive one, until it finds one that can be applied, or falls back to the unoptimized code, which redisplays the entire window. To be able to pull this trick, the display engine maintains a set of flags, each one of which tells whether a particular kind of event happened since last redisplay. These flags are consulted when the display engine must decide which optimization, if any, is applicable. One of these flag variables is the window start point: as long as it stays put, Emacs does not need to bother recomputing it, and does not need to invalidate the information it keeps about where in the buffer text is the window start point, given the current value of point. When a post-command-hook forces a value of window-start, some of these optimizations are inapplicable, so Emacs responsiveness suffers. For example, when follow-mode is on, Emacs frequently needs to redisplay the same window twice in a row, instead of just once. > However, it would probably be easy to handle if there would be a > windows-specific option or call-back that could control if the > window should be recentered or not. That's not what I had in mind. Instead, we could have special code in the display engine that would automatically scroll the other window(s) when follow-mode says they should. IOW, when Emacs redisplays some window because something changed in it, the display engine could decide right there and then that some other windows need to be redisplayed, and moreover, compute their window-start point automatically or by calling some Lisp. After all, the relations that determine the window-start of the windows which participate in follow-mode is quite simple: the next window should begin where the previous one ends. All of this could be done in a single redisplay cycle, thereby avoiding the need for a post-command-hook in the first place. The benefit would be not only a more efficient redisplay, but also faster Emacs, because many commands do not affect any display, and many others do not affect windows that are under follow-mode, so in this case a post-command-hook forces Emacs to perform unnecessary redisplay. > While I'm at it, I realized today that the responsiveness when using > follow-mode was better when running the cursor up and down compared to left > and right. When looking into the details I saw that the arrow keys no > longer were bound to previous- and next-char, so we need to apply the patch > below to follow-mode (I don't have write-access to the archives). I installed this in your name. Thanks.