[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?
Fri, 28 Sep 2012 08:28:07 -0400
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