Re: jit-lock refontifies too much

[martin rudalics <rudalics@gmx.at>]

 > It would be better just to keep comparing until you reach a line that
 > previously was fontified.  After all, the line that was not fontified
 > before certainly should get fontified, if it is on the screen.  But a
 > subsequent line that was previously fontified may not need to be
 > changed.
 >

This might work for a single window on one and the same buffer.  With
two windows there might remain some unfontified stretch between the
portions shown in the windows.  When I modify text in the first window
and that would affect the context of the second window, the information
might not get through the unfontified area.  On the other hand comparing
until I reach fontified text (or point-max) regardless of whether text
is on screen would be expensive.

 > Since the question is whether there is a realistic case where it would
 > have visible impact.  If nobody really wants to set
 > jit-lock-context-time to zero, that's not a realistic example.
 > So we still don't know whether there is a realistic case where it
 > would have visible impact.

Disciplined users insert/delete both delimiters of comments or strings
simultaneously.  They could profitably set `jit-lock-context-time' to
zero.  I'm too undisciplined.

 >
 > That is why I suggested recording these ppss values in text
 > properties of the first character on a line--so that they would stay
 > around for comparison later.

That would be fine.  But recording these properties for each and every
line fontified would introduce too much overhead.  It would be enough
recording only those things really needed (fields 0, 3, 4, and 7 of
ppss).  In any case this would have to be done for every buffer even if
it isn't modified ever.  A lazy strategy would require some clairvoyance
about which lines would get modified or a before-change-hook anyway.

Saving ppss in text properties at bol would be certainly useful for
font-locking purposes.  But these ppss would usually be invalid and
therefore not useful for other purposes.  And they would have to be
recycled and recalculated after a context change has been detected.

 >
 >     That would be overly expensive.  I rewrote all this with ppss, two
 >     markers, a before-change-functions hook and without any text properties.
 >     It seems to work but needs some further testing.
 >
 > That is interesting.  I would not have expected it to work.

It will "work" until you or Stefan have a closer look at it.

 > However, this would require doing that computation for each change,
 > and that could be rather expensive, right?

For the first in a sequence of changes.  That is, when you enter/delete
a stretch of text I would initially record the ppss for the line begin
following the first character you entered/deleted.  Usually, you then
modify text (a) within 0.5 secs and (b) adjacent to the position of the
last text change.  In such cases I would not record anything for
subsequent modifications.  If you now sit for 0.5 secs, refontification
will be needed iff the syntactic context really changed.

If, within 0.5 secs, you change text on another line I give up.  More
precisely, "change text on another line" means "change text outside the
region enclosed by the markers".  Initially this region ranges from the
begin of the line where a modification starts to the begin of the line
following the end of the modification.  In particular, I give up for
backward-deletions of newlines preceding the start of the region,
indent-region, filling, or replacing all occurrences of some text in a
buffer.  Although, setting `jit-lock-context-time' to zero could avoid
refontification in some of these cases.

 >
 > One advantage for the idea of saving it in a text property for the
 > first character on each line is that it only has to be checked
 > when it is time to refontify.
 >

If "time to refontifiy" means "during `jit-lock-context-fontify'" that's
what I try to do presently.

 > Another possible advantage is: if things are not in sync for the first
 > line after the end of the changed text, it might be in sync on a
 > subsequent line, and that could avoid refontifying most of the lines
 > on the screen.
 >

I can think of two interpretations for "things are not in sync":

1. Buffer text contains something like an unclosed string/comment.  For
    an unclosed comment a subsequent line may "compensate" the error if
    it contains a comment terminator and comments don't nest.  In this
    case one could avoid refontification.  A paren in column zero will
    compensate such errors too.  But in that case correcting an error
    would require that subsequent lines are refontified in order to clear
    the warnings installed by font-lock.  Hence it might be difficult to
    derive a general method.

2. Text on screen has not been yet fontified correctly.  In this case
    "things are not in sync" for `jit-lock-context-time' seconds.  With
    the default settings I would have to get things out of sync and back
    into sync within 0.5 secs.  Doing this within the region enclosed by
    the markers should be handled by my approach.  Changes outside the
    region would indicacte the presence of a skilled user - someone who'd
    probably profit from setting `jit-lock-context-time' to a value less
    than the default.