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 #52 received at 8355 <at> debbugs.gnu.org (full text, mbox):
> From: Antoine Levitt <antoine.levitt <at> gmail.com>
> Cc: larsi <at> gnus.org, 8355 <at> debbugs.gnu.org
> Date: Fri, 11 Dec 2020 09:35:20 +0100
>
> > 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.
OK, thanks.
> 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?
That's what I did, or at least I thought I did.
> 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.
A reproduction recipe for where you see this happening more that will
be appreciated.
I also don't understand how you arrived at the 10% figure. Can you
elaborate?
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.