From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#16129: 24.3.50; Emacs slow with follow-mode when buffer ends before last window Date: Tue, 7 Jan 2014 09:13:19 +0100 Message-ID: References: <83bnzpu622.fsf@gnu.org> <8338l1t6ip.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8f3ba12dfe2c0704ef5cf27e X-Trace: ger.gmane.org 1389082452 26968 80.91.229.3 (7 Jan 2014 08:14:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Jan 2014 08:14:12 +0000 (UTC) Cc: 16129-done@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 07 09:14:16 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 1W0Rnj-0008RW-Ae for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Jan 2014 09:14:15 +0100 Original-Received: from localhost ([::1]:39262 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0Rni-00043a-66 for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Jan 2014 03:14:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0Rna-00043P-Un for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2014 03:14:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0RnW-0003h7-IB for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2014 03:14:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54345) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0RnW-0003h3-FN for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2014 03:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W0RnW-0000cD-24 for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2014 03:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2014 08:14: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-done@debbugs.gnu.org id=D16129.13890824042304 (code D ref 16129); Tue, 07 Jan 2014 08:14:01 +0000 Original-Received: (at 16129-done) by debbugs.gnu.org; 7 Jan 2014 08:13:24 +0000 Original-Received: from localhost ([127.0.0.1]:40130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0Rmt-0000b5-Em for submit@debbugs.gnu.org; Tue, 07 Jan 2014 03:13:24 -0500 Original-Received: from mail-wi0-f171.google.com ([209.85.212.171]:44973) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0Rmq-0000aw-Io for 16129-done@debbugs.gnu.org; Tue, 07 Jan 2014 03:13:21 -0500 Original-Received: by mail-wi0-f171.google.com with SMTP id bz8so3785149wib.10 for <16129-done@debbugs.gnu.org>; Tue, 07 Jan 2014 00:13:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5HVSIz1Gt9cXAnV+3Snz8n3K7QNZ64Eis/rBSHAinyg=; b=y083ivif44g81h5iLD5H/1dFhAyHftfBtME5OJpaW7414lHXkDOnWsD4DUA3caD5fm zze5tZjaeFM1J1qxfAodP+UUmC3FCPn+RZlQLSw7dl8N9GT6A7HBpNt6slgNUBfqMAuB SMdNF3GnJQ21KhHNu8PgwTxrs7JuHppQn2Ia3WxEYPoOdF1qp2wjIc7dm5IGxOp9+zRu 8lFGoQqE7IHZJK2P9tlZ6wnN47IfPfUcaWQtHu+Po68rmjy2fTSx9NNAKQ5JBvawSSMz HVa4XwQxzIk5/yx7BP5vQaeZT2XLLPhwDuSCg+Lwxl8UgKenoQqTGbLHqPEYVFuhlyk3 NUuw== X-Received: by 10.180.109.107 with SMTP id hr11mr15589330wib.56.1389082399613; Tue, 07 Jan 2014 00:13:19 -0800 (PST) Original-Received: by 10.216.223.140 with HTTP; Tue, 7 Jan 2014 00:13:19 -0800 (PST) In-Reply-To: <8338l1t6ip.fsf@gnu.org> 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:83090 Archived-At: --e89a8f3ba12dfe2c0704ef5cf27e Content-Type: text/plain; charset=ISO-8859-1 Hi! Thanks, I tried it out on the trunk, and it seems to be working correctly! 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. 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. 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). Thanks for your help, Anders === modified file 'lisp/follow.el' --- lisp/follow.el 2014-01-01 07:43:34 +0000 +++ lisp/follow.el 2014-01-07 07:48:40 +0000 @@ -311,7 +311,7 @@ (set-default symbol value))) (defvar follow-cache-command-list - '(next-line previous-line forward-char backward-char) + '(next-line previous-line forward-char backward-char right-char left-char) "List of commands that don't require recalculation. In order to be able to use the cache, a command should not change the On Mon, Jan 6, 2014 at 5:33 PM, Eli Zaretskii wrote: > > Date: Mon, 6 Jan 2014 09:20:03 +0100 > > From: Anders Lindgren > > Cc: Stefan Monnier , 16129@debbugs.gnu.org > > > > I think the incorrect state occurs when the new early exit occurs from > > redsplay_window. When I added the condition "&& PT == w->last_point", > both > > the recentering problem and speed issues were solved. > > Indeed, this was my conclusion as well. (Except that PT is not quite > right, as the window could be displaying a buffer that is not the > current one at that early point in redisplay_window.) > > What this caused was that the window redisplay was mistakenly skipped, > but then we marked that window's display "accurate", which confused > the heck out of the display engine. > > So I installed the patch below to fix this regression, and I'm marking > this bug done. Feel free to reopen if there are any leftovers. > > Btw, I strongly recommend against messing with window-start (or > anything else that potentially requires redisplay) in a > post-command-hook: doing so disables some important redisplay > optimizations, and can easily trigger subtle misfeatures. I suggest > to look for a better method to do what follow-mode needs to do, even > if that means we'd have to implement a special hook we don't yet have. > > Thanks. > > === modified file 'src/xdisp.c' > --- src/xdisp.c 2014-01-01 17:44:48 +0000 > +++ src/xdisp.c 2014-01-06 16:21:39 +0000 > @@ -15621,7 +15621,8 @@ redisplay_window (Lisp_Object window, bo > && REDISPLAY_SOME_P () > && !w->redisplay > && !f->redisplay > - && !buffer->text->redisplay) > + && !buffer->text->redisplay > + && BUF_PT (buffer) == w->last_point) > return; > > /* Make sure that both W's markers are valid. */ > > --e89a8f3ba12dfe2c0704ef5cf27e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi!

Thanks, I tried it out on the trunk= , and it seems to be working correctly!


=
I'm open to reimplementing follow-mode in another way, if you thin= k that it's necessary. However, there are two different uses of set-win= dow-start, and maybe we don't need to change both:

* Normally, when the position of the active window chan= ge, 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-s= tart to ensure that the display engine doesn't recenter the window.

Of the two uses, I only consider the second a problem. = However, it would probably be easy to handle if there would be a windows-sp= ecific option or call-back that could control if the window should =A0be re= centered or not.


While I'm at it, I realized today th= at the responsiveness when using follow-mode was better when running the cu= rsor 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).

Thanks for your help,
=A0 =A0 Anders

=3D=3D=3D modified file 'lisp/follow.el'

--- lisp/follow.el 2014-01-01 07:43:3= 4 +0000

+++ lisp/follow.el 2014-01-07 07:48:4= 0 +0000

@@ -311,7 +311,7 @@

=A0 (set-default symbol value)))

=A0

=A0(defvar follow-cache-command-list

-=A0 '(next-line previous-line forward-char backward-char= )

+=A0 '(next-line previous-line forward-char backward-char= right-char left-char)

=A0=A0 "List of commands that don't require recalcul= ation.

=A0

=A0In order to be able to use the cache, a command should not= change the




On Mon,= Jan 6, 2014 at 5:33 PM, Eli Zaretskii <eliz@gnu.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> > Date: Mon, 6 Jan 2014 09:20:03 +0100
> From: Anders Lindgren <andlind= @gmail.com>
> Cc: Stefan Monnier <mon= nier@iro.umontreal.ca>, 161= 29@debbugs.gnu.org
>
> I think the incorrect state occurs when the new early exit occurs from=
> redsplay_window. When I added the condition "&& PT =3D=3D= w->last_point", both
> the recentering problem and speed issues were solved.

Indeed, this was my conclusion as well. =A0(Except that PT is not qui= te
right, as the window could be displaying a buffer that is not the
current one at that early point in redisplay_window.)

What this caused was that the window redisplay was mistakenly skipped,
but then we marked that window's display "accurate", which co= nfused
the heck out of the display engine.

So I installed the patch below to fix this regression, and I'm marking<= br> this bug done. =A0Feel free to reopen if there are any leftovers.

Btw, I strongly recommend against messing with window-start (or
anything else that potentially requires redisplay) in a
post-command-hook: doing so disables some important redisplay
optimizations, and can easily trigger subtle misfeatures. =A0I suggest
to look for a better method to do what follow-mode needs to do, even
if that means we'd have to implement a special hook we don't yet ha= ve.

Thanks.

=3D=3D=3D modified file 'src/xdisp.c'
--- src/xdisp.c 2014-01-01 17:44:48 +0000
+++ src/xdisp.c 2014-01-06 16:21:39 +0000
@@ -15621,7 +15621,8 @@ redisplay_window (Lisp_Object window, bo
=A0 =A0 =A0 =A0&& REDISPLAY_SOME_P ()
=A0 =A0 =A0 =A0&& !w->redisplay
=A0 =A0 =A0 =A0&& !f->redisplay
- =A0 =A0 =A0&& !buffer->text->redisplay)
+ =A0 =A0 =A0&& !buffer->text->redisplay
+ =A0 =A0 =A0&& BUF_PT (buffer) =3D=3D w->last_point)
=A0 =A0 =A0return;

=A0 =A0/* Make sure that both W's markers are valid. =A0*/


--e89a8f3ba12dfe2c0704ef5cf27e--