bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Eli Zaretskii]

tags 24179 fixed
close 24179 
quit

> From: Alex <agrambot@gmail.com>
> Cc: 24179@debbugs.gnu.org
> Date: Thu, 11 Aug 2016 16:20:07 -0600
> 
> >> You're right, though it also seems to happen when using C-n. I tried
> >> turning off line-move-visual and the delay is still there.
> >
> > I have now fixed that problem as well.
> 
> Thanks, I don't see it anymore with C-n. It's expected that the delay
> with M-g c and magit-blame's `n' command is still present, right?

I don't see any perceptible delay here, but maybe I missed something.
Do some "M-g c" work faster than others?  Or some other motion
commands are faster than "M-g c 1350 RET"?  If so, can you give a
recipe for a "fast" and a "slow" command?

In general, setting scroll-conservatively to a large value makes
redisplay slightly slower, because in some situations it must work
harder to find the smallest possible scroll amount.  If a
before-string inserted by magit-blame uses up many screen lines, the
fix I added might indeed cause a slowdown, although they'll have to be
quite a lot of screen lines for that to become perceptible, I think.

Another potential reason for slower redisplay, specific to magit-blame
and similar modes, is that a significant proportion of lines in a
typical window comes from overlay strings, not from buffer text.  When
Emacs needs to determine the position of window-start for next
redisplay, it starts from point and goes back till it finds a suitable
buffer position, which would put point some specific number of pixels
from the window-start.  When Emacs goes back, it uses the number of
lines in the buffer as the first approximation, then adjusts that
place as needed.  With many display or overlay strings in a window,
that first approximation is usually way off, so the process of
adjusting it to find the correct place needs to consider more
potential candidates, and this takes longer.

> Though your new commit does seem to lessen those delays, if that means
> anything.

The original delay was not a delay.  What happened is that the first
redisplay after "M-g c 1350 RET" would end up with point off the
screen, and the cursor at the end of the first screen line.
Immediately after that another redisplay would fix that by scrolling
the window.  So it took 2 redisplay cycles to react to the command;
now it takes only one.

> > OK.  If no new issues come up due to my changes, please close the bug
> > in a few days.
> 
> Hopefully the above did that.

No, it didn't.  When you include control commands in a message, you
should BCC control@debbugs.gnu.org for the bug tracker to take notice
(like I did with tis message).  If you want to just close the bug (as
opposed to add some tags), an easier way is to CC
24179-done@debbugs.gnu.org.

Thanks.