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

[James McClain]

There is no real-life use case at all where I can see this problem
happening, I was just curious as to why.
Thank you for figuring that out,
Glad to see I'm not crazy!

Regards,

James

On Fri, May 6, 2016 at 2:15 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 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.