Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering comparisson between emacs23 and emacs26.3

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Thu, 16 Apr 2020 23:13:16 +0300
> 
> > 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.

> (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.

> 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.

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.

> 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.