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

[Martin Stjernholm]

Stefan Monnier <address@hidden> wrote:

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

Indeed it is.

> The problem is: how to get font-lock to refontify
>
>     s[foo]{
>       bar
>     }x
/.../
> 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.

That doesn't work very well while the thing is entered, does it? First
you see "s[foo]{" while it's being entered, then you see the next line
" bar", and lastly "}x". Your patterns will never see the whole
construct at once. (They will however see the buffer end, or even
worse some completely unrelated code that happen to be on the
following lines and which might confuse them.)

A text property can help if you can recognize the construct from the
first line only, but then you'll have to make another pattern that
matches the "}" and contains logic to extend the property put in place
by the pattern matching the first line.

Another problem is that the "bar" part can get arbitrarily large if
it's code, in which case it becomes a performance problem to put a
property on it to refontify the whole thing. Another case to consider
is that the intervening code can contain nested constructs of the same
sort. (I'm not saying it's so in Perl - I'm extending the discussion
to the general case.)

If the construct can't be recognized from the first line alone, which
might very well happen for a C-like declaration, then I see no choice
but to have a function that can find the start when the last line is
entered. That function can of course use various properties put in
place by the major mode to speed up its work. (CC Mode, for instance,
already has some internal properties to cache interesting syntactic
positions, and I'm thinking about extending that approach a lot.)

> I haven't seen code that bothers with stickiness when handling
> *-multiline, so it doesn't seem complex.

It's still more complex to understand and use text properties at all
than to just return a region, especially if one wants the code to work
in the two major emacs flavors which have completely different
interfaces in this area.