[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: font-lock-syntactic-keywords obsolet?

From: Dmitry Gutov
Subject: Re: font-lock-syntactic-keywords obsolet?
Date: Mon, 11 Jul 2016 03:06:30 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Thunderbird/47.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]