Re: Bug in font-lock-syntactic-keywords handling?

[immerrr again]

On Mon, Oct 6, 2014 at 5:14 PM, Stefan Monnier <address@hidden> wrote:
>
> That seems like a performance bug (it re-fontifies something that's
> already been fontified), indeed, but I don't see why that would cause
> something to "fail".
>
> If it really causes a failure, I suspect that the failure is really
> caused by an underlying bug in the specific syntactic-keywords rules,
> which merely gets triggered by this performance bug.
>
>
>         Stefan

The problem is that it doesn't unfontify the already processed chunk beforehand.

It this particular situation, when I encounter a "--[[" comment
starter I need to be sure that there are no dashes before
("---[[...\n" is a single-line comment by design) and that this
starter is not inside another comment. I did this the "smart" way: I
checked (elt ppss 4) of the *second* dash, so that when there's
something like "--X-[[" with X being the point, the point is already
inside a single-line comment. That single check covers both cases,
yet, as most "smart" things do, it breaks unexpectedly.

This one breaks when "--[[" is already propertized as a comment opener
and the second dash is already a part of that comment. This causes
comment-open matcher to fail and simple two-step propertize function
[1],

    (lambda (limit) (or (try-close-comment limit) (try-open-comment limit)))

doesn't work, since there is no comment to be closed at the beginning
of the chunk, the opener is already propertized and thus skipped and
the closer is never invoked again.

Cheers,
immerrr

1. This lambda is a simplified version of
https://github.com/immerrr/lua-mode/blob/master/lua-mode.el#L868-L872