[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: font-lock-syntactic-keywords: evaluating arbitrary elisp inside matc
Re: font-lock-syntactic-keywords: evaluating arbitrary elisp inside matchers?
Tue, 25 Sep 2012 09:20:23 -0400
Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)
>> Here's your problem: the comments/strings you want to match may span
>> several lines, yet the patterns on font-lock-syntactic-keywords cannot
>> reliably match more than a single line (because when a line is modified,
>> font-lock only looked for that pattern in that line, for example).
> If I follow the documentation correctly, this can be worked around by using
> `font-lock-extend-region-functions', isn't it?
Yes, although writing an appropriate function can be difficult, and even
if you manage to do it, it will still mean that whenever you modify
a line inside a 1000-line string, the whole 1000-line string will
be refontified which can lead to performance problems.
> The snippet is great. I, for one, have somehow missed the "<"/">" syntax
> descriptors. But I have a concern: what if closing long bracket,
> i.e. "]==]",
> is after `end', doesn't it need an extra matcher rule for that?
Well, you'll want to make sure you don't go past `end' and if the ]==]
is not found before `end' you just don't put any "closing syntax
property". That's not a problem, because that ]==] will be found in
some later invocation of the syntax-propertize function where `end' will
be after the ]==].
> As for 23-vs-24 question, I really look forward to the moment when
> I can safely drop backward compatibility for lua-mode, but in the
> meanwhile, I guess, I'll need to look into the font-lock code to see
> how to do the same in Emacs23.
Yes, you can do the same with font-lock-syntactic-keywords, of course.