font-lock-extend-region (was: [sigra@home.se: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows])

[Stefan Monnier <monnier@iro.umontreal.ca>]

> DONE.  In the process, I moved the processing of font-lock-lines-before
> from font-lock-default-fontify-region into
> font-lock-after-change-function and jit-lock-after-change, so as to be
> able to stop them interfering with eachother.

OK, having thought some more about it, I'm really convinced doing it in
after-change-function is the wrong way: your jit-lock code won't always do
the right thing, because even though you mark the whole extended region for
refontification, jit-lock may refontify it in chunks (and maybe not even in
the intended order).

So I will move the font-lock-extend-region code to
font-lock-default-fontify-region where it belongs (which is why that's also
the place where font-lock-extra-lines was handled and where
font-lock-multiline is handled).

Now IIUC that means it'll break some/all of your uses of that variable.
Clearly you won't be pleased, but think about it this way: it'll save you
bug reports from users seeing odd behavior in conjunction with jit-lock.

Anyway, as I said, for your use case what you should be using is an
after-change-functions hook that puts a font-lock-multiline property.
But as you noted, this will only work if your hook happens to be placed in
after-change-functions before font-lock's own (or jit-lock's, though that
one is much less serious).

Also as I mentioned elsewhere, another solution is to change your
requirement such that some of the responsibility of the refontification is
passed on to contextual refontification: I would tend to prefer this
solution myself (it moves work away from the time-critical path).
But admittedly, setting jit-lock-context-time to 0 is believed to be a bit
too costly right now (not enough optimizations), so if you really want the
refontification to be immediate (rather than delayed by 0.5 idle seconds),
it's not a good solution.

So what I offer you is to introduce a new
`font-lock-before-after-change-functions' which is just like
after-change-functions except it's run by font-lock's (or jit-lock's)
after-change-function and before it does anything else.
You can then use this hook to place a function that computes the extended
region and places a font-lock-multiline property on it.

Do we have a deal?


        Stefan