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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Antoine Levitt <antoine.levitt <at> gmail.com>
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:47:06 +0200
> 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.