>>> The customizable variable `font-lock-lines-before' is not honored by >>> jit-lock mode. >> >> I know what that means in therms of what the code does, but I'm wondering in >> which circumstance it makes a visible difference to the end user. >> Do you have a test case?
> Suppose not: Wouldn't that mean `font-lock-lines-before' is useless? Not at all. font-lock-lines-before has not been introduced to force refontification of the previous lines but because the N previous lines are needed as context in order to properly refontify the current line. Now the code does in fact refontify the previous lines, but it is a side-effect rather than one of the original goals. > It's not very difficult to contrive test cases for this. By default > `font-lock-multiline' is nil. `font-lock-fontify-anchored-keywords' > won't alter it - the appropriate lines have been commented out. Write > an arbitrary multiline pattern. Now font-lock won't give it the > `font-lock-multiline' text property and jit-lock not necessarily reset > its `fontified' text property after a change. `font-lock-after-change', > on the other hand, may refontify it provided `font-lock-lines-before' is > large enough. Please show me a test case. > However, I believe that `font-lock-lines-before' is a brute force > approach to handle such cases and could remarkably slow down editing if > it were honored by jit-lock mode. Multiline patterns are too delicate > and should be treated in a completely different way. Indeed, but nobody has put the work needed to handle them properly. font-lock-multiline is one hack, font-lock-lines-before is another, font-lock-fontification-face-function is yet another. Stefan _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel