GNU bug report logs - #8355
24.0.50; Boxes in mode-line and scrolling

Previous Next

Package: emacs;

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

From: Antoine Levitt <antoine.levitt <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 8355 <at> debbugs.gnu.org
Subject: Re: bug#8355: 24.0.50; Boxes in mode-line and scrolling
Date: Fri, 11 Dec 2020 10:08:03 +0100

11 December 2020 09:47 +01, Eli Zaretskii:
>> 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.

OK, I'll try it out more; I'm not running master "in production" yet
because of some issue with mu4e not limiting the mail it shows me that I
haven't had time to debug yet.

> I also don't understand how you arrived at the 10% figure.  Can you
> elaborate?

I assumed small, random variations in height of amplitude δh around a
reference height h0, and n δh >> h0. Then the place where you fall
before rounding is randomly distributed. You'll get movement only if
you've rounded up or down by about the half-separation, which should
happen a fraction 1/pixel height of the time. I have lines about 20px
tall, so that's 5%; I multiply by two to account for the possibility of
having rounded both up and down. If anything this should be an
overestimate; but again my assumptions are probably unrealistic (eg for
instance in my tex files the δh is always positive, which might explain
why I always see movement in the same direction).

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.