unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Antoine Levitt <antoine.levitt@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: larsi@gnus.org, 8355@debbugs.gnu.org
Subject: bug#8355: 24.0.50; Boxes in mode-line and scrolling
Date: Fri, 11 Dec 2020 10:08:03 +0100	[thread overview]
Message-ID: <874kkssob0.fsf@inria.fr> (raw)
In-Reply-To: <835z583f1x.fsf@gnu.org>



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





  reply	other threads:[~2020-12-11  9:08 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-27 13:41 bug#8355: 24.0.50; Boxes in mode-line and scrolling Antoine Levitt
2020-12-08 15:05 ` Lars Ingebrigtsen
2020-12-08 15:56   ` Antoine Levitt
2020-12-08 18:18     ` Lars Ingebrigtsen
2020-12-08 18:29       ` Eli Zaretskii
2020-12-08 18:19     ` Eli Zaretskii
2020-12-08 18:27       ` Lars Ingebrigtsen
2020-12-08 18:33         ` Eli Zaretskii
2020-12-09 16:17           ` Eli Zaretskii
2020-12-09 17:01             ` Lars Ingebrigtsen
2020-12-09 17:13               ` Eli Zaretskii
2020-12-09 17:24                 ` Lars Ingebrigtsen
2020-12-09 20:47                   ` Antoine Levitt
2020-12-10  3:34                     ` Eli Zaretskii
2020-12-11  8:35                       ` Antoine Levitt
2020-12-11  8:47                         ` Eli Zaretskii
2020-12-11  9:08                           ` Antoine Levitt [this message]
2020-12-11 11:59                             ` Eli Zaretskii
2020-12-11 12:25                               ` Antoine Levitt
2020-12-14 18:25                                 ` Eli Zaretskii
2020-12-14 19:02                                   ` Antoine Levitt
2020-12-14 19:27                                     ` Eli Zaretskii
2020-12-14 18:26                   ` Eli Zaretskii
2020-12-14 19:05                     ` Lars Ingebrigtsen
2020-12-14 19:30                       ` Eli Zaretskii
2020-12-15  5:23                         ` Lars Ingebrigtsen
2021-01-20 17:09                           ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874kkssob0.fsf@inria.fr \
    --to=antoine.levitt@gmail.com \
    --cc=8355@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).