> The problem is that in perl-mode some syntax-table text-properties are set > in font-lock-syntactic-keywords, while others are set in > font-lock-syntactic-face-function, and that font-lock+jit-lock applies > font-lock-syntactic-keywords to "all" the buffer but only applies > font-lock-syntactic-face-function to the displayed part of the buffer. > So some of those properties can be missing if you start display from > somewhere else than the beginning of the buffer. Hmm...
In general this problem occurs with patterns like foo --- bar where syntax or appearance of `bar' depend on something font-lock calculates when it encounters `foo' and font-lock's scan stops at the `---'. In the special case I believe it was displaying a file immediately as foo --- window-start --- bar and jit-lock - triggered by redisplay - fontified the `bar' part only. However, the problem may also occur when you change within a window foo --- ba to foo --- bar which to my knowledge neither font-lock nor jit-lock can handle. Or, insert a stretch of text containing `foo' and `bar' such that `foo' ends up before `window-start' and `bar' within the window. This would be handled by pure font-lock but here `font-lock-syntactic-keywords' might fail with jit-lock since neither `font-lock-syntactically-fontified' gets adjusted properly nor is the inserted region fontified immediately. Misfontifications may persist even when you "scroll `foo' into the window" since fontification routines usually don't refontify text - although they might set multiline text properties correctly - this could be probably fixed in the actual example. Misfontifications are not corrected by stealth fontification routines either since the latter do not refontify displayed text. I intend to handle this with `jit-lock-context-fontify' in a reasonable way. To make this practicable, however, I should reduce refontification overhead introduced by the latter first. > Already applying font-lock-syntactic-keywords to "all" the buffer defeats > the purpose of jit-lock. Applying font-lock-syntactic-face-function in the > same way would defeat it even more, and this only because perl-mode uses it > in a sneaky way (perl-mode is the only mode which suffers from this > problem). jit-lock breaks font-lock's handling of syntax-table properties anyway. Having syntactic properties behave correctly only for positions preceding `font-lock-syntactically-fontified' means that I can't parse text after that position reliably with `parse-sexp-lookup-properties' non-nil. By the way, doesn't `tex-font-lock-syntactic-face-function' try a similar hack with "\verb?...?" constructs? And there's also the commented out `python-font-lock-syntactic-face-function'. _______________________________________________ Emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
