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

Previous Next

Full log

Message #63 received at 24179 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 24179 <at> debbugs.gnu.org
Subject: Re: bug#24179: 25.1;
 scroll-conservatively over SCROLL_LIMIT may put point in the wrong
 place
Date: Sat, 13 Aug 2016 09:52:10 +0300

> From: Alex <agrambot <at> gmail.com>
> Cc: 24179 <at> debbugs.gnu.org
> 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.

Yes, I see that, thanks.  I will think if something can be done in
that case.

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

I'm not sure I understand the question.  Redisplay cycles happen in
Emacs all the time when Emacs is idle, but usually they quickly
determine that nothing has to be done, so you don't see them
happening.  In this case, Emacs sees that point is not inside the
window, so it attempts to correct that.

Previous Next

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