[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:04:04 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 17.04.2020 09:11, Eli Zaretskii wrote:

I think you will find that many more do than you seem to assume.  Even
just redisplaying a window does this in many cases (to find the proper
place for window-start position).  C-n and C-p do as well.  And when
scroll-conservatively is in effect, almost every command that moves
point does.

Would that be... almost all of them?

I don't think I understand the question.  Please elaborate.

I think the majority of commands either move point, or have the potential to do so. Even those that do completing-read, for example.

(Indeed, the fact that (setq scroll-conservatively 1) doesn't work as
well as one would expect is a real bug IMO).

I'm not aware of any bugs in that, so please describe what you think
is a bug in more detail.

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.

In any case, if there is a way to dynamically detect these cases and
disable redisplay skipping for them, I'd like to try that out.

Yes, jit-lock-defer-time is that way.  But you already know that.

No, it speeds up redisplay. It doesn't make *sure* that redisplay is not skipped.

To do that, need to modify the condition of skipping redisplay.

If that's not what you meant, then what exactly would you like to be
able to detect?  The move_it_* functions are the entry point to the
display simulation code, and they are used all over the place.

Perhaps detect the cases when move_it_* was used inside the command's implementation?

Even more if there was a way to put the results of "simulated redisplay"
to use in the "real" redisplay later.

That happens automatically, since the 'fontified' property they
produce is left on the buffer text.

That might be sufficient if we assume that font-lock is always the slowest part of redisplay (for some commands it might not always be true, but I'm guessing here).

But with that assumption, the extra condition of not skipping redisplay could be simplified (?) to only checking whether the current screen has been fontified already (i.e. 'fontified' is non-nil). If it's fontified, we won't skip redisplay.

reply via email to

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