Re: checking jit-lock-defer-multiline

[martin rudalics]

> Could you give some example (concrete or hypothetical) where the
> problem you mention comes up?

I'm looking for a practical font-lock-multiline substitute.  I dislike
font-lock-multiline because it may introduce too much overhead during
typing, especially when the multiline property spans a couple of lines.
Using jit-lock-defer-multiline should ideally resolve this because it's
processed when I don't type.

Now suppose I set a jit-lock-defer-multiline property from the beginning
of foo till the end of bar as in

foo
...
bar

The property would get assigned iff foo is textually followed by bar on
some line below.  If some user changes bar to baz I would have to act in
some way and the jit-lock-defer-multiline should help me to rescan the
text from foo till baz.  With the recent change the following might
happen: If the user replaces bar by baz _and_ inserts some text on the
line below baz, redisplay would call to fontify these lines "as usual".
jit-lock-context-fontify, on the other hand, would eventually refontify
from a position below these lines.  Refontification would not see foo in
either case.

However, I believe the extra variable is not needed.  The following should
suffice:

           (when (and jit-lock-context-unfontify-pos
                      (< jit-lock-context-unfontify-pos next)
                      (>= jit-lock-context-unfontify-pos start)
                      (not (get-text-property start 'jit-lock-defer-multiline)))
             (setq jit-lock-context-unfontify-pos next))