[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: Stefan Monnier
Subject: Re: font-lock-syntactic-keywords: evaluating arbitrary elisp inside matchers?
Date: Fri, 28 Sep 2012 08:28:07 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

> Hold on, do I understand procedure correctly in the following
> situation: suppose, we're propertizing an arbitrary buffer region, big
> enough not to be matched in single attempt; suppose, first match region -
> from `begin1' to `end1' - contains exactly one opening long bracket and its
> long bracket of the same level is located beyond `end1' point, and there's
> no other opening long bracket in between. Am I right that the next match
> invocation will operate on region starting from `end1 + 1'?


> If yes, then unless there's a rule that can match closing long
> brackets, the closing long bracket won't be found and thus won't be
> propertized, or will it?

There is such a rule: the definition of lua-syntax-propertize begins by
calling lua-syntax-propertize-string-or-comment-end which:

   and then in lua-syntax-propertize-string-or-comment I'd use syntax-ppss
   to check the parser state (i.e. determine if I'm in a type-b comment or
   delimited-string corresponding to a long-bracket construct as opposed to
   some type-a comment or standard string, or plain old code), and if I'm
   in one of those long-bracket-constructs, use (nth 8 ppss) to find the
   beginning, count the number of = used there, then search for the
   matching ]==] pattern and place the matching "> b" or "|" syntax on the
   second closing bracket.

so while the second call is for "end1+1 ... end2", your code will go
back to the beginning of the long bracket to figure out its end and then
look for that end again (which might show up before end2 this time, tho
maybe not).

-- Stefan

reply via email to

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