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 #29 received at 26445 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alexander Miller <alexanderm <at> web.de>
Cc: 26445 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
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 10:06:41 +0300

> Cc: 26445 <at> debbugs.gnu.org
> From: Alexander Miller <alexanderm <at> web.de>
> Date: Thu, 13 Apr 2017 23:07:48 +0200
> 
> On 13/04/17 22:05, Noam Postavsky wrote:
> > Yes, maybe the answer to this bug is just not to set
> > scroll-conservatively so high then.
> That does help with the height difference introduced by thinly boxed 
> text. Unfortunately there are
> still other cases where where a scroll stutter still remains, caused by 
> unicode symbols.
> For example using prettify-symbols-mode to replace -> with ⭢ or configs 
> for programs like
> polybar which naturally contain a host of characters like    🔇 ⏭.

That depends on what font you have installed that's used to display
those characters.  It is best to have fonts of approximately the same
height.

> I guess if you guys say it cannot be reasonably done I'll consider 
> getting rid of my margin altogether,

There's no need to get rid of margins, as I think the problem you
describe is purely aesthetic, and quite expected when you have lines
of different height.  Why does it bother you so much?

> though I'm still curious why there's no problem when the cursor is at 
> the very start of the line.

Because the window layout begins at the first screen line, and the
y-coordinate of a screen line is its top edge.  So the display engine
can always position the first screen line exactly, whereas where the
last screen line ends depends on what is in-between, and the scroll
margin at the end of the window forces the last pixel of the point's
line to be above the margin.

I also think that if you produce text where lines have more than just
2 different heights, you will see a similar problem while scrolling
up as well.

> Then there's also the second part the bug report - the cursor switching 
> columns when scrolling.

That's not a bug: the button-face line is slightly longer than the
lines in the default face, and scrolling attempts to preserve the
x-coordinate of point, not the column (because the same column could
be at very different x-coordinate due to fonts, faces, inline images,
etc.).  You can see what's going on if you put the cursor on a
boxed-text line, then scroll: you will see a small jitter of the
cursor in the horizontal direction.

Previous Next

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