GNU bug report logs - #23457
24.5; interactive use of next-line and previous-line (holding down C-n or C-p) lag in a buffer with all spaces and newlines

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: James McClain <jamezmcclain <at> gmail.com>
Cc: nicolas <at> petton.fr, 23457 <at> debbugs.gnu.org
Subject: bug#23457: 24.5; interactive use of next-line and previous-line (holding down C-n or C-p) lag in a buffer with all spaces and newlines
Date: Fri, 06 May 2016 12:15:02 +0300

> From: James McClain <jamezmcclain <at> gmail.com>
> Date: Fri, 6 May 2016 01:43:55 -0700
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 23457 <at> debbugs.gnu.org
> 
> For this to happen there needs to be many lines of just spaces and a
> newline. I talked about in a previous message having 67 of those
> lines, but I believe on my linux box it required more (less than 100
> though). You also need to go to the very end of the file M->, then
> scroll up through the lines up to the top. I did not make that clear.

Ah!  Now I do see this.  And this doesn't happen in *scratch*, right?

To make the problem go away, do this:

  M-x set-variable RET bidi-paragraph-direction RET left-to-right RET

In any buffer whose major mode supports some programming language
(like *scratch*, which supports Emacs Lisp), the above variable is
already set to that value  by default, so the problem won't happen.

Anyway, now that I see the problem and understand its reasons, is
there any real-life use case where this problem happens?  If so,
please describe that use case.  Otherwise, this is expected behavior,
and this bug should be closed.

> I experience lag doing this, to be clear about what I mean by that. I
> can cancel by using C-g, but unless I do that, I cannot execute
> commands until emacs finishes moving up lines. Which takes much longer
> than if instead of all spaces, I had instead one period before the
> newline.

The contents of the buffer that you describe make redisplay work very
hard, so the time it takes to refresh the display after you move point
is long.  On my machine, a single C-p from the end of a 200-line
buffer with all-blank lines takes 2 sec in an unoptimized build, and
less than 1 sec in an optimized build.

> I cannot remember if I tested with with emacs -Q -nw on linux.

No need, now that I understand the problem.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.