Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]

[Stefan Monnier]

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