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

[Eli Zaretskii]

> From: James McClain <jamezmcclain@gmail.com>
> Date: Fri, 6 May 2016 01:43:55 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, 23457@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.