>> - why can't they use the font-lock-multiline property?
>> - why can't they use the jit-lock-defer-multiline property?
> One argument for a hook alternative to these things is that it might
> not be efficient/convenient to spread text properties all over the
> place:
You misunderstood: I'm not particularly happy about either of the
*-multiline text-properties. I wrote both of them, but neither of them is
satisfactory, really.
But I want to better understand the limitations and strength of each
approach before adding a new hook.
When I added the jit-lock-defer-multiline property (mostly for perl-mode),
I first considered adding a hook somewhat like Alan's but it turns out that
it's pretty damn difficult to write this hook:
The problem is: how to get font-lock to refontify
s[foo]{
bar
}x
when it's changed to
s[foo]{
bar
}xe
since the first `bar' should be treated like a string whereas the second
should be treated like code.
Now, when I'm in the middle of font-locking, I've done the work of figuring
out that I'm in an s/foo/bar/ expression and I can easily add
a text-property on the whole thing. OTOH using something like Alan's hook,
I'm stuck because if I see "}xe" I don't even know if I'm within code, or
within a string, let along if the } happens to be closing the second arg of
an `s' operation. It can be done, of course, but it's a fair bit of
redundant work especially since you have to make sure it's not too slow
in the "usual" case (where the hook shouldn't do anything).
I suspect that in the case mentioned in the subject the problem might
be similar.
> o Text properties stay behind when the buffer changes, and so they
> might become invalid. Adding code to correctly remove them before
> that can be tricky.
font-lock (and jit-lock) should take care of that for you.
> o Putting text properties in place and handling stickiness etc
> properly is decidedly more complex than just returning a region
> from a hook.
I haven't seen code that bothers with stickiness when handling *-multiline,
so it doesn't seem complex.
I do agree that for the awk-mode case, Alan's hook is probably one of the
most straightforward solution. But I must also say I'm not convinced by the
resulting behavior in awk-mode (or c-mode for that matter). After all, it
catches the problem of forgetting a \, so the warning face should be applied
to the \n char where the \ is missing, not to the opening/closing quote.
This would tie in with another "todo" feature: provide font-lock-keywords
specific to a particular syntatic context: you could thus have separate
keywords highlighted in comments and in strings. Quite handy for
Javadoc thingies.
Stefan
_______________________________________________
Emacs-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-devel
