itemprop="text">
I'm trying to create a custom syntax
language file to highlight and help with creating new documents in Sublime Text 2. I
have come pretty far, but I'm stuck at a specific problem regarding Regex searches in
the tmLanguage file. I simply want to be able to match a regex over multiple lines
within a YAML document that I then convert to PList to use in Sublime Text as a package.
It won't work.
href="https://regex101.com/r/iH3gL0/1" rel="nofollow">This is my
regex:
/(foo[^.#]*bar)/
And
this is how it looks inside the tmLanguage YAML
document:
patterns:
-
include: '#test'
repository:
test:
comment: Tester pattern
name: constant.numeric.xdoc
match:
(foo[^.#]*bar)
If I
build this YAML to a tmLanguage file and use it as a package in Sublime Text, I create a
document that uses this custom syntax, try it out and the following
happens:
This WILL
match:
foo 12345
bar
This WILL NOT
match:
foo
12345
bar
In
a Regex tester,
they should and will both match, but in my tmLanguage file it does not
work.
I also already tried to add modifiers to
my regex in the tmLanguage file, but the following either don't work or break the
document entirely:
match:
(/foo[^.#]*bar/gm)
match: /(/foo[^.#]*bar/)/gm
match:
/foo[^.#]*bar/gm
match:
foo[^.#]*bar
Note: My Regex rule works in the tester, this problem occurs in the tmLanguage
file in Sublime Text 2
only.
Any help is
greatly appreciated.
EDIT: The reason I use a
match instead of begin/end clauses is because I want to use capture groups to give them
different names. If someone has a solution with begin and end clauses where you can
still name 'foo', '12345' and 'bar' differently, that's fine by me
too.
I found that this is impossible to
do. This is directly from the href="http://manual.macromates.com/en/language_grammars" rel="nofollow">TextMate
Manual, which is the text editor Sublime Text is based
on.
<...>
Note that the regular
expressions are matched against only a single
line of the
document at a time. That means it is not possible to use
a
pattern that matches multiple lines. The reason for this is
technical:
being able to restart the parser at an arbitrary line
and having to
re-parse only the minimal number of lines affected by an edit.
In most
situations it is possible to use the begin/end model to overcome
this
limitation.
My
situation is one of the few in which a begin/end model cannot overcome the limitation.
Unfortunate.
