From: Alex <agrambot@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 24179@debbugs.gnu.org
Subject: bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place
Date: Fri, 12 Aug 2016 16:01:19 -0600 [thread overview]
Message-ID: <87h9apzlxs.fsf@gmail.com> (raw)
In-Reply-To: <83k2fmdqc0.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 12 Aug 2016 17:17:19 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
> I don't see any perceptible delay here, but maybe I missed something.
> Do some "M-g c" work faster than others? Or some other motion
> commands are faster than "M-g c 1350 RET"? If so, can you give a
> recipe for a "fast" and a "slow" command?
Using the recipe function above, try M-g c 1737. That temporarily leaves
the point at the top before going to the correct position. M-g c 1700
does not do this.
Using magit-blame in version.el with emacs maximized do M-g c 1148 and
press `n' one or two times. One of these should briefly show the cursor
at the top of the screen.
> Another potential reason for slower redisplay, specific to magit-blame
> and similar modes, is that a significant proportion of lines in a
> typical window comes from overlay strings, not from buffer text. When
> Emacs needs to determine the position of window-start for next
> redisplay, it starts from point and goes back till it finds a suitable
> buffer position, which would put point some specific number of pixels
> from the window-start. When Emacs goes back, it uses the number of
> lines in the buffer as the first approximation, then adjusts that
> place as needed. With many display or overlay strings in a window,
> that first approximation is usually way off, so the process of
> adjusting it to find the correct place needs to consider more
> potential candidates, and this takes longer.
Alright, that makes sense.
> The original delay was not a delay. What happened is that the first
> redisplay after "M-g c 1350 RET" would end up with point off the
> screen, and the cursor at the end of the first screen line.
> Immediately after that another redisplay would fix that by scrolling
> the window. So it took 2 redisplay cycles to react to the command;
> now it takes only one.
OK, that would explain it. By "delay" I was referring to this momentary
period where the cursor is shown at the end of the top screen line.
Is it necessary to be in this wrong position for a redisplay cycle?
> No, it didn't. When you include control commands in a message, you
> should BCC control@debbugs.gnu.org for the bug tracker to take notice
Ah, right. Thanks.
next prev parent reply other threads:[~2016-08-12 22:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-07 21:15 bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place Alex
2016-08-08 2:39 ` Eli Zaretskii
2016-08-08 5:42 ` Alex
2016-08-08 15:31 ` Eli Zaretskii
2016-08-08 16:35 ` Alex
2016-08-08 16:58 ` Eli Zaretskii
2016-08-08 17:22 ` Alex
2016-08-08 17:35 ` Eli Zaretskii
2016-08-11 15:06 ` Eli Zaretskii
2016-08-11 22:20 ` Alex
2016-08-12 14:17 ` Eli Zaretskii
2016-08-12 22:01 ` Alex [this message]
2016-08-13 6:52 ` Eli Zaretskii
2016-08-13 16:59 ` Alex
2016-08-13 17:25 ` Eli Zaretskii
2016-08-14 18:27 ` Eli Zaretskii
2016-08-14 20:05 ` Alex
2016-08-11 16:39 ` bug#24179: 24179 Jonas Bernoulli
2016-08-11 17:15 ` Eli Zaretskii
2016-08-11 18:29 ` Jonas Bernoulli
2016-08-11 19:55 ` Eli Zaretskii
2016-08-11 20:07 ` Eli Zaretskii
2016-08-11 22:19 ` Jonas Bernoulli
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h9apzlxs.fsf@gmail.com \
--to=agrambot@gmail.com \
--cc=24179@debbugs.gnu.org \
--cc=eliz@gnu.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.