[Top][All Lists]

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

Re: font-lock-syntactic-keywords: evaluating arbitrary elisp inside matc

From: immerrr again...
Subject: Re: font-lock-syntactic-keywords: evaluating arbitrary elisp inside matchers?
Date: Tue, 25 Sep 2012 15:31:24 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6

On 09/25/2012 05:03 AM, Stefan Monnier wrote:
> 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?

> (defun lua-syntax-propertize (start end)
>   (goto-char start)
>   (lua-syntax-propertize-string-or-comment-end end)
>   (funcall
>    (syntax-propertize-rules
>     ("\\(?:\\(?:^\\|[^-]\\)\\(-\\)-\\)?\\([\\)=*["
>      (1 "< b") ;; Only applied if sub-group1 exists.
>      (2 (prog1 (unless (match-beginning 1) (string-to-syntax "|"))
>           (lua-syntax-propertize-string-or-comment-end end)))))
>    start end))>

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?

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


reply via email to

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