Re: Text Properties And Buffer Modification

[Eli Zaretskii]

> Date: Sat, 08 Dec 2018 10:42:31 +0100
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
> 
>  > 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.
> 
> The current description of try_window_id in xdisp.c is
> 
>        This function attempts to redisplay a window by reusing parts of
>        its existing display.  It finds and reuses the part that was not
>        changed, and redraws the rest.  (The "id" part in the function's
>        name stands for "insert/delete", not for "identification" or
>        somesuch.)
> 
> Could you kindly add that "scrolling parts of the displayed stuff"
> there somehow.

There's a much more detailed description in the commentary before the
function itself, did you read that?

> For a simple minded reader like me, it's intuitively
> not clear that it can do such virtual scrolling of unchanged contents.

The scrolling is not virtual, it's a real scrolling of what's on the
glass (reflected in the glyph matrix, of course).

> Maybe also tell how many such unaltered chunks can be reused and/or
> how large they must be.

AFAIU, there are no limitations.

>  > 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.
> 
> It wouldn't matter much but I think that redisplay could handle an
> overlay change just like any text property change.
> 
>  >> 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"?
> 
> I was asking myself why it's important to treat text property changes
> in an optimized way in try_window_id because I thought they wouldn't
> be affected much by typing.  And as far as font-locking is concerned,
> it invalidates the rest of the buffer parts shown in a window anyway
> whenever a text change occurs.

Text properties have the advantage that it's very easy to know where
they start and end in the buffer, and thus this function can know
where in the window the changes begin by just comparing buffer
positions.  By contrast, to know what portions are affected by an
overlay needs a costly access to the overlay data, and the information
needed to deduce which parts of the window are affected by the overlay
changes is not readily available.  I believe this is why the function
gives up if overlays have changed.