Re: Text Properties And Buffer Modification

[Eli Zaretskii]

> Date: Thu, 06 Dec 2018 19:46:42 +0100
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
> 
>  > The optimization I had in mind is try_window_id.  You will see there
>  > that this optimization is disabled if overlays were changed, but not
>  > if the buffer (including text properties) was changed.  you will also
>  > see there that buffer-modification tick is used there to update the
>  > unchanged text at beginning and end of the buffer when necessary.
> 
> This must be the
> 
>    if (w->last_overlay_modified != OVERLAY_MODIFF)
>      GIVE_UP (200);
> 
> form.  I clearly missed that.

That's one of them.  The other is the snippet that begins with

  if (MODIFF > SAVE_MODIFF


> IIUC try_window_id is based on the idea that typing should be fast
> (that is, cause no excessive redisplay) as long as it does not happen
> within an overlay.

Not sure I agree with this interpretation.  My mental model of
try_window_id was that it attempts to reuse what is already on display
by scrolling parts of the displayed stuff, and then inserting/deleting
a few lines that have changed.  It determines which parts of the
display could be reused by analyzing where are the changes in the
buffer relative to the displayed portion.  How did we arrive at the
situation where only some lines need to be changed is immaterial, and
in general is not by typing, quickly or otherwise.

try_window_id gives up if overlay changed because it finds the
portions of the displayed text to be reused by looking at buffer text,
and overlays invalidate the assumption that only buffer text
determines what's on screen.

> But why do we optimize changes of text properties as well?

I'm not sure I understand the question.  What do you mean by "optimize
changes of text properties"?

> This is one of those I looked at and found no difference between
> overlay and text changes.  Now the former of these
> 
>    w->last_modified = accurate_p ? BUF_MODIFF (b) : 0;
>    w->last_overlay_modified = accurate_p ? BUF_OVERLAY_MODIFF (b) : 0;
> 
> is checked by try_window_id as
> 
>    if (w->last_modified == 0)
>      GIVE_UP (6);
> 
> and the latter is needed by the check I cited above.  But is there an
> additioal twist?

Since we rejected the case where overlays changed, we don't need to
check it again.

In general, the above condition means that the window's glyph matri
might not be up to date, so we cannot safely reuse it.