GNU bug report logs -
#8355
24.0.50; Boxes in mode-line and scrolling
Previous Next
Reported by: Antoine Levitt <antoine.levitt <at> gmail.com>
Date: Sun, 27 Mar 2011 13:42:02 UTC
Severity: normal
Tags: fixed, moreinfo
Found in version 24.0.50
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #49 received at 8355 <at> debbugs.gnu.org (full text, mbox):
10 December 2020 04:34 +01, Eli Zaretskii:
>> From: Antoine Levitt <antoine.levitt <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 8355 <at> 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
This bug report was last modified 4 years and 126 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.