[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering

From: Dmitry Gutov
Subject: Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering comparisson between emacs23 and emacs26.3
Date: Fri, 17 Apr 2020 20:52:32 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 17.04.2020 20:35, Eli Zaretskii wrote:
From: Dmitry Gutov<address@hidden>
Date: Fri, 17 Apr 2020 20:04:04 +0300

1. (setq scroll-conservatively 1)

2. Visit xdisp.c.

3. Lean on C-n.

4. From time to time, you will see point jump into the middle of the
screen, when font-lock takes too long, apparently (or maybe it
corresponds to GC pauses).

This shouldn't happen because next-line only moves by one line.
And it doesn't.

What doesn't? It clearly does happen. And 'next-line' only moves by one line (the docstring says so, at least).

What happens is that Emacs is sometimes unable to
keep up with input, so when it comes to displaying the next screenful,
point is already more than 1 line below the window's end.  So Emacs

I know. But these are internal details, which shouldn't affect the observable behavior this much.

And I'm not convinced that, if redisplay didn't happen, Emacs can't decide that scrolling happened anyway. After all, if that was the case, then in the original problem scenario (floor C-v, see Emacs freeze after a while), after Emacs unfreezes, the window start would have been the same (or almost the same) as when Emacs stopped updating the screen.

That's why the special value of 101 was introduced: so that this
recentering never happens.

This bug basically makes lower values (which I personally would otherwise choose to use, probably even the value of 1) frustratingly unreliable. That's both bad and non-obvious. Emacs clearly doesn't honor scroll-conservatively's description.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]