Re: Text Properties And Buffer Modification

[martin rudalics <rudalics@gmx.at>]

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

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.  For a simple minded reader like me, it's intuitively
not clear that it can do such virtual scrolling of unchanged contents.
Maybe also tell how many such unaltered chunks can be reused and/or
how large they must be.

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

OK.  I was looking for the rationale of try_window_id and that's what
I came up with.  Till now I naively imagined try_window_id to reuse
parts of the old glyph matrix as long as a user did _not add or remove
a newline_ thus causing the part below the line where the change
occurred to move within the glyph matrix and consequently invalidate
the entire matrix and trigger a redisplay of the entire window.  The
fact that the code is smarter than that has eluded me so far.

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

martin