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

Previous Next

Full log

View this message in rfc822 format

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24179 <at> debbugs.gnu.org
Subject: bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place
Date: Fri, 12 Aug 2016 16:01:19 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

> 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?

Using the recipe function above, try M-g c 1737. That temporarily leaves
the point at the top before going to the correct position. M-g c 1700
does not do this.

Using magit-blame in version.el with emacs maximized do M-g c 1148 and
press `n' one or two times. One of these should briefly show the cursor
at the top of the screen.

> 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.

Alright, that makes sense.

> 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, that would explain it. By "delay" I was referring to this momentary
period where the cursor is shown at the end of the top screen line.

Is it necessary to be in this wrong position for a redisplay cycle?

> No, it didn't.  When you include control commands in a message, you
> should BCC control <at> debbugs.gnu.org for the bug tracker to take notice

Ah, right. Thanks.

Previous Next

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