GNU bug report logs - #26445
26.0.50; Scroll margin and cursor movement working incorrectly when scrolling over different height lines

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: alexanderm <at> web.de, 26445 <at> debbugs.gnu.org
Subject: Re: bug#26445: 26.0.50; Scroll margin and cursor movement working
 incorrectly when scrolling over different height lines
Date: Fri, 14 Apr 2017 09:50:58 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Thu, 13 Apr 2017 16:05:31 -0400
> Cc: Alexander Miller <alexanderm <at> web.de>, 26445 <at> debbugs.gnu.org
> 
> >> I think the root issue might be that scroll-margin is given in lines,
> >> and then it's translated to pixels under the assumption that lines are
> >> all using the default height.
> >
> > If that's the problem, I see no good solutions here, because
> > scroll-conservatively > 100 explicitly requests to position point as
> > close to the window edge as possible, and the alternating lines of
> > different height in the recipe of this bug report force us to stop one
> > line earlier every other scroll.  Am I missing something?
> 
> I would have to sketch this out on paper to be sure, but you're probably right.

The only solution I see is to use window-vscroll to position point
more accurately one line before scroll-margin.  That sounds gross to
me, though, and will cause a similar "stutter" on the first screen
line of the window, so someone else in some other use case will
probably complain.

If we do want to make such changes, the place to make them is in
line-move and line-move-partial, not in xdisp.c.

> >  When a
> > line is taller than the canonical height, positioning point on it
> > might enter the scroll-margin, and we still need to back up, don't we?
> > IOW, the above code still move "by lines", and will "stutter" if lines
> > are intermittently of different height.  What possible solution could
> > we come up with in such situations?  It seems to me that the user gets
> > what they asked for.
> 
> Yes, maybe the answer to this bug is just not to set
> scroll-conservatively so high then.

Or accept the consequences of it being high.

Previous Next

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