> 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. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
