[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point i
From: |
Alex |
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 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
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.
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, (continued)
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Eli Zaretskii, 2016/08/07
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Alex, 2016/08/08
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Eli Zaretskii, 2016/08/08
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Alex, 2016/08/08
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Eli Zaretskii, 2016/08/08
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Alex, 2016/08/08
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Eli Zaretskii, 2016/08/08
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Eli Zaretskii, 2016/08/11
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Alex, 2016/08/11
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Eli Zaretskii, 2016/08/12
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place,
Alex <=
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Eli Zaretskii, 2016/08/13
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Alex, 2016/08/13
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Eli Zaretskii, 2016/08/13
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Eli Zaretskii, 2016/08/14
- bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place, Alex, 2016/08/14
bug#24179: 24179, Jonas Bernoulli, 2016/08/11