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]

The linux box has nothing in common with my windows box, there should
be no configurations shared that effect emacs, especially since I run
it with -Q.
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.

Here is another take on the recipe, hopefully I can clear up any confusion.
This is without resizing the window, so window-body-width should be 80.
1. .\emacs-25.0.93.exe -Q
2. C-x b test-2 <ret>
3. <f3>
4. C-u 80 <space>
5. C-j
6. <f4>
7. C-u 120 <f4>
8. You should now be at the bottom of the buffer and at the first column,
    but it doesn't hurt to hit M-> and C-a, so do that.
9. Now try moving up to the top of the buffer with C-p

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.

I cannot remember if I tested with with emacs -Q -nw on linux. I will
report on this tomorrow as well as test the windows build on a newly
deployed computer and maybe test it in a virtual box VM.  I may also
try setting it up tonight if I have the energy.

On Fri, May 6, 2016 at 12:59 AM, Nicolas Petton <nicolas@petton.fr> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I believe you.  I just cannot reproduce this on any machine to which I
>> have access.
>
> I also can't reproduce it on my Linux box with Emacs 25.0.93.
>
> Nico