checking jit-lock-defer-multiline

checking jit-lock-defer-multiline

[martin rudalics]

The recent change to `jit-lock-fontify-now' may disable checking the
`jit-lock-defer-multiline' property in a number of cases.  It might make
sense to introduce a variable `jit-lock-defer-multiline' with default
nil.  Modes like `perl-mode' would set this to t and the check in
`jit-lock-fontify-now' become:

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

Re: checking jit-lock-defer-multiline

[Stefan Monnier]

> The recent change to `jit-lock-fontify-now' may disable checking the
> `jit-lock-defer-multiline' property in a number of cases.  It might make
> sense to introduce a variable `jit-lock-defer-multiline' with default
> nil.  Modes like `perl-mode' would set this to t and the check in
> `jit-lock-fontify-now' become:

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

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


        Stefan

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))

Re: checking jit-lock-defer-multiline

[Stefan Monnier]

> 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))

Oh, that makes more sense.  Thank you.


        Stefan