Re: font-lock-syntactic-keywords obsolet?

[Dmitry Gutov <dgutov@yandex.ru>]

On 07/11/2016 01:11 AM, Alan Mackenzie wrote:

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

It works, thanks.

Here's a comparatively minor problem: normally, "foo" in the closer has 
the default face. But if I backspace over the semicolon that follows it, 
and then type it again, "foo" gets the font-lock-string-face.

Similarly if I do backspace over and retype the closing double-quote 
character instead.

> I know that the processing is currently
> slow in such a large raw string.  It is probably possible to optimise
> this.  Whether it is worthwhile is the question.

I don't know. Probably not if that will involve making the code even 
more complex.

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

Not sure. That description sounds like it's about performance, and not 
about correctness. Since you're only mentioning scanning forward, that 
doesn't seem to account for problems with when I'm fiddling with the 
closing delimiter.