bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Antoine Levitt]

10 December 2020 04:34 +01, Eli Zaretskii:
>> From: Antoine Levitt <antoine.levitt@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 8355@debbugs.gnu.org
>> Date: Wed, 09 Dec 2020 21:47:48 +0100
>> 
>> movement does remain the rule and no movement the exception.
>
> IME, with that file and the default settings, it's the other way
> around.
>
> If the changes I installed don't improve things considerably, perhaps
> I should revert them?

It's still better than the previous behavior so I would keep it. But the
question is what is the correct thing to do. 

I know nothing about how it's implemented, but I would assume a simple
round-to-nearest should do the trick, at least a very high fraction of
the time? So you've got a set of integers (the pixel positions of the
line), a current integer (the current line) and you want to move to
another integer in the set, approximately by some prescribed amount n
(the screen height). If you do the simplest thing which is to move by n
and round to the nearest line, then if you go down once and up once the
only way you can fail to come back to the original point is if the shift
you applied to round to a line is larger than the half-separation
between lines. So if I have lines of about 20px, I would expect that to
happen maybe 10% of the time; and I would also expect that sometimes the
line shift is up and sometimes down. But in my tests, even with your
patch, I see it happening a lot more than 10%, and always in the same
direction (going down then up shifts one line up). So either it's
something to do with the pixel distribution of my tex files which is
messing this up, or I misunderstand the algorithm.

Best,
Antoine