There was some code in the mix designed to stop too much expansion of
a region when there were humongous macros. (A few years back somebody
had complained about the speed in processing a ~5,000 line macro.)
Unfortunately, this code got caught up in raw string processing. I hope
the following patch fixes it.
I'm confused. If, as we discussed before, syntax properties are applied
in before/after-functions, why does c-font-lock-declarations need to be
concerned with scanning for raw string bounds?
The raw string bounds have nothing to do with c-font-lock-declarators.
It's just that that function takes a bound which was hardly ever needed,
since the function stops when it reaches something which signalled the
end of a sequence of declarators (for example, a semicolon). Hence the
fact that the bound given was wrong didn't get noticed. However, with
raw strings in the game, when (point-max) was the bound, the function
actually ended up fruitlessly scanning to (point-max) rather than to the
`limit' it should have been scanning to.
The limit to c-font-lock-declarators is now `(min limit (point-max))'.
That way, when the buffer is narrowed to less than `limit', there won't
be an out of bounds error, and when there are unterminated raw strings,
there won't be useless scanning past `limit' either.
I'm not sure if the above will help much, but I hope it does.