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: Mon, 6 Jan 2014 09:20:03 +0100 Message-ID: References: <83bnzpu622.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01493de038c5cd04ef48edd3 X-Trace: ger.gmane.org 1388996471 22654 80.91.229.3 (6 Jan 2014 08:21:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jan 2014 08:21:11 +0000 (UTC) Cc: 16129@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 06 09:21: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 1W05Qy-0001H9-Vq for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jan 2014 09:21:17 +0100 Original-Received: from localhost ([::1]:33086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W05Qy-0003vj-A1 for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jan 2014 03:21:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W05Qp-0003vY-UF for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2014 03:21:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W05Qk-0006YA-SK for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2014 03:21:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51975) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W05Qk-0006Y4-ON for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2014 03:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W05Qk-0003bb-3s for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2014 03:21: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: Mon, 06 Jan 2014 08:21: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.138899640913773 (code B ref 16129); Mon, 06 Jan 2014 08:21:01 +0000 Original-Received: (at 16129) by debbugs.gnu.org; 6 Jan 2014 08:20:09 +0000 Original-Received: from localhost ([127.0.0.1]:37761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W05Ps-0003a4-FA for submit@debbugs.gnu.org; Mon, 06 Jan 2014 03:20:09 -0500 Original-Received: from mail-we0-f178.google.com ([74.125.82.178]:52567) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W05Po-0003Zt-9n for 16129@debbugs.gnu.org; Mon, 06 Jan 2014 03:20:05 -0500 Original-Received: by mail-we0-f178.google.com with SMTP id u57so15647960wes.9 for <16129@debbugs.gnu.org>; Mon, 06 Jan 2014 00:20:03 -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=iYI66nLC5TGwglTnp2XmKDnhCfZA1OV16GMaB5xJVSQ=; b=G3g7lYh9vKDfGnbGK8e+DWiXjyGnXaGzXyx2f6oTO/14yURJMuGY6+M8Yi/mpYNo6G wefndQXEWuHTQXtGvHQl3j8EvRUgg03WeBW+TfglyR+iMGiPCse7aH5BrzFTAEMNHVcI alaqs6OTs6n/WtPL/Xl9yeX7Fzee8nhN9T8rSIrg+F5eKngD5tSe3isMh1Pw7DJXzZjZ mSl8HwdV1nwGW1L78ReaKexbeZsPY9dD10qiMf0SGIWHWF+eou3nfxtr9FmAfgkJVTC8 xEjOZR2yY2VKCjwu19KCx+JkO8tV7WkURG86rkvlbAIMR/mQlwShqrBBcbB8Il4Zv3jr uowg== X-Received: by 10.194.236.9 with SMTP id uq9mr59196992wjc.31.1388996403445; Mon, 06 Jan 2014 00:20:03 -0800 (PST) Original-Received: by 10.216.223.140 with HTTP; Mon, 6 Jan 2014 00:20:03 -0800 (PST) In-Reply-To: <83bnzpu622.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:83053 Archived-At: --089e01493de038c5cd04ef48edd3 Content-Type: text/plain; charset=ISO-8859-1 Hi! 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. However, I don't know if this is the correct way to handle this, or if it breaks anything else. -- Anders On Mon, Jan 6, 2014 at 4:45 AM, Eli Zaretskii wrote: > > Date: Mon, 6 Jan 2014 00:13:38 +0100 > > From: Anders Lindgren > > Cc: 16129@debbugs.gnu.org > > > > When "redisplay_window" is called, it goes into the case where > > "try_cursor_movement" is called. > > > > Inside this routine, the row is picked up. The row (when using the > TUTORIAL > > example) has start and end at 46229. The point and last_point, however, > are > > 46228, so it assumes that the point haven't moved since the last > redisplay. > > > > Clearly, "last_point" and "row" are not consistent with each other, which > > is assumed by try_cursor_movement (if I read it correctly). > > > > The routine first declare this to be a "success" (in the neither forward > > nor backward case). Later in the function it comes to the following > > statement: > > > > if (PT < MATRIX_ROW_START_CHARPOS (row) > > || PT > MATRIX_ROW_END_CHARPOS (row)) > > > > This fails, making the function return " CURSOR_MOVEMENT_MUST_SCROLL", > > which is turn cause "redisplay_window" to recenter the window. > > Thanks. Your description is correct, and I already found that this is > what happens. (The silence doesn't necessarily mean no one is doing > anything about the bug report ;-) > > I didn't yet have the time to figure out why the last_point field of > the window is equal to point, while last_cursor_vpos points to the > screen line that does not contain point; my current suspicion is that > the post-command-hook somehow causes that. But given that this is > what happens, you will always see a recenter, because it means Emacs > lost track of where point is in the window. When Emacs is confused > about this, it always recenters as the last resort. > > This still doesn't say why redisplay is so slow in this case, which > was the initial bug reported here. Stay tuned. > --089e01493de038c5cd04ef48edd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi!

I think the incorrect state occurs = when the new early exit occurs from redsplay_window. When I added the condi= tion "&& PT =3D=3D w->last_point", both the recenterin= g problem and speed issues were solved. However, I don't know if this i= s the correct way to handle this, or if it breaks anything else.

=A0 =A0 -- Anders


On Mon, Jan 6, 2014 at 4:45 AM, Eli Zar= etskii <eliz@gnu.org> wrote:
> Date: Mon, 6 Jan 2014 00:13:38 +0100 > From: Anders Lindgren <andlind= @gmail.com>
> Cc: 16129@debbugs.gnu.org=
>
> When "redisplay_window" is called, it goes into the case whe= re
> "try_cursor_movement" is called.
>
> Inside this routine, the row is picked up. The row (when using the TUT= ORIAL
> example) has start and end at 46229. The point and last_point, however= , are
> 46228, so it assumes that the point haven't moved since the last r= edisplay.
>
> Clearly, "last_point" and "row" are not consistent= with each other, which
> is assumed by try_cursor_movement (if I read it correctly).
>
> The routine first declare this to be a "success" (in the nei= ther forward
> nor backward case). Later in the function it comes to the following > statement:
>
> =A0 if (PT < MATRIX_ROW_START_CHARPOS (row)
> =A0 =A0 =A0 || PT > MATRIX_ROW_END_CHARPOS (row))
>
> This fails, making the function return " CURSOR_MOVEMENT_MUST_SCR= OLL",
> which is turn cause "redisplay_window" to recenter the windo= w.

Thanks. =A0Your description is correct, and I already found that this= is
what happens. =A0(The silence doesn't necessarily mean no one is doing<= br> anything about the bug report ;-)

I didn't yet have the time to figure out why the last_point field of the window is equal to point, while last_cursor_vpos points to the
screen line that does not contain point; my current suspicion is that
the post-command-hook somehow causes that. =A0But given that this is
what happens, you will always see a recenter, because it means Emacs
lost track of where point is in the window. =A0When Emacs is confused
about this, it always recenters as the last resort.

This still doesn't say why redisplay is so slow in this case, which
was the initial bug reported here. =A0Stay tuned.

--089e01493de038c5cd04ef48edd3--